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ABSTRACT 



A system and method for facilitating electronic tr 
using a biometric are disclosed. The system for facilitating 
electronic transactions using a biometric comprises a smart- 
card-reader transaction system. The method comprises 
determining if a transaction violates an established rule, 
such as a preset spending limit. The method also comprises 
notifying a user to proffer a biometric sample in order to 
verify the identity of said user, and detecting a proffered 
biometric at a sensor to obtain a proffered biometric sample. 
The method additionally comprises verifying the proffered 
biometric sample and authorizing a transac 
upon verification of the proffered biometric sample. 
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METHODS AND APPARATUS FOR CONDUCTING 
ELECTRONIC TRANSACTIONS USING 
BIOMETRICS 

CROSS-REFERENCE TO RELATED 
APPLICATIONS 

[0001] This application is a continuation-in-part and 
claims priority to U.S. application Ser. No. 09/652,899, 
entitled "Methods And Apparatus For Conducting Elec- 
tronic Transactions," filed Aug. 31, 2000, the '899 applica- 
tion itself claims the benefit of: U.S. Provisional Application 
No. 60/151,880, filed Aug. 31, 1999; U.S. Provisional Appli- 
cation No. 60/164,668, filed Nov. 9, 1999; U.S. Provisional 
Application No. 60/165,577, filed Nov. 15, 1999; and, U.S. 
Provisional Application No. 60/201,635, filed May 3, 2000. 
All of the above-listed applications are incorporated herein 
by reference. 

FIELD OF INVENTION 
[0002] The invention relates generally to methods and 
apparatus for conducting network transactions. More par- 
ticularly, the invention relates to systems for authenticating 
and conducting business over data networks (such as the 
Internet) using a personal identifier such as a biometric. 

BACKGROUND OF INVENTION 

[0003] In recent years, many consumers have discovered 
the convenience and economy of purchasing goods and 
services electronically. A number of channels for electronic 
purchases (commonly called "e -purchases") are available, 
including shop-at-home television networks, call-in 
responses to television advertisements, and the like. Most 
recently, direct purchasing via the Internet has become 
extremely popular. 

[0004] In a typical Internet transaction, a consumer gen- 
erally identifies goods and/or services for purchase by 
viewing an online advertisement such as a hypertext markup 
language (HTML) document provided via a World Wide 
Web (WWW) browser. Payment typically occurs via a 
charge card number that is provided via a secure channel 
such as a secure sockets layer (SSL) connection that is 
established between the consumer and the merchant. A 
charge card account number is typically a sixteen-digit 
charge card number. Credit or charge card numbers typically 
comply with a standardized format having four spaced sets 
of numbers, as represented by the number "0000 0000 0000 
0000". The first five to seven digits are reserved for pro- 
cessing purposes and identify the issuing bank, card type, 
etc. The lasl sixteenth digit is used as a sum check for the 
sixteen-digit number. The intermediary eight-to-ten digits 
are used to uniquely identify the customer. The merchant 
then processes the charge card number by, for example, 
receiving direct authorization from the card issuer, then the 
merchant completes the transaction. The SSL standard is 
described by, for example, "The SSL Protocol Version 3.0" 
dated Nov. 18, 1996, which is available online at http:// 
home.netscape.com/eng/ssl3 draft302.txt, the entire con- 
tents of which are incorporated herein by reference. 
[0005] Although millions of transactions take place every 
day via the Internet, conventional SSL transactions often 
exhibit a number of marked disadvantages. Although SSL 
typically provides a secure end-to-end connection that pre- 



vents unscrupulous third parties from eavesdropping (e.g., 
"sniffing") or otherwise obtaining a purchaser's charge card 
number, the protocol does not provide any means for ensur- 
ing that the charge card number itself is valid, or that the 
person providing the card number is legally authorized to do 
so. Because of the high incidence of fraud in Internet 
transactions, most charge card issuers consider network 
transactions to be "Card Not Present" transactions subject to 
a higher discount rate. Stated another way, because of the 
increased risk from "Card Not Present" transactions, most 
charge card issuers charge the merchant a higher rate for 
accepting card numbers via electronic means than would be 
charged if the card were physically presented to the mer- 

[0006] To improve the security deficiencies inherent in 
transporting charge card numbers over unsecure networks, 
many have suggested the use of "smart cards." Smart cards 
typically include an integrated circuit chip having a micro- 
processor and memory for storing data directly on the card. 
The data can correspond to a cryptographic key, for 
example, or to an electronic purse that maintains an elec- 
tronic value of currency. Many smartcard schemes have 
been suggested in the prior art, but these typically exhibit a 
marked disadvantage in that they are non-standard. In other 
words, merchants typically must obtain new, proprietary 
software for their Web storefronts to accept smartcard trans- 
actions. Moreover, the administration costs involved with 
assigning and maintaining the cryptographic information 
associated with smart cards have been excessive to date. 

[0007] The Secure Electronic Transaction (SET) standard 
has been suggested to improve the security of Internet 
transactions through the use of various cryptographic tech- 
niques. Although SET does provide improved security over 
standard SSI. transactions, the administration involved with 
the various public and private keys required to conduct 
transactions has limited SET's widespread acceptance. SET 
also requires special software for those merchants wishing to 
support SET transactions. 

[0008] Existing digital wallet technology, such as the 
digital wallet technology provided by, for example, 
GlobeSet, Inc., 1250 Capital of Texas Highway South, 
Building One, Suite 300, Austin, Tex. 78746, provides a 
means for customers to utilize transaction card products 
(e.g.. credit, charge, debit, smart cards, account numbers and 
the like) to pay for products and services on-line. In general, 
digital wallets are tools which store personal information 
(name, address, charge card number, credit card number, 
etc.) in order to facilitate electronic commerce or other 
network interactions. The personal information can be 
stored on a general server or at a client location (PC or 
Smartcard) or on a hybrid of both a general server and a 
client server. The digital wallet general server is comprised 
of a Web server and a database server which centrally houses 
the customer's personal and credit card information, shop- 
ping preferences and profiles of on-line merchants. 

[0009] In an exemplary embodiment, a digital wallet per- 
forms functions such as single sign on/one password, auto- 
matic form filling of check out pages, one- or two-click 
purchasing, personalization of Websites, on-line order and 
delivery tracking, itemized electronic receipts, and custom- 
ized offers and promotions based upon spending patterns 
and opt-ins. More particularly, a one-click purchase acti- 
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vates the wallet and confirms the purchase at the same time. 
A two-click check out first activates the wallet, then the 
second click confirms the purchase. 

[0010] In use, the wallet bookmark is typically clicked by 
the customer and an SSL session is established with the 
Wallet server. A browser plug-in is executed and the cus- 
tomer supplies an ID/password or smartcard for authentica- 
tion in order to gain access to the wallet data. When 
shopping at an on-line merchant, the appropriate wallet data 
is transferred from the wallet server to the merchant's Web 

[0011] Further still, even with the use of electronic wallets 
and smartcards, there is a desire to further safeguard elec- 
tronic transactions against evolving threats. While existing 
systems may provide for the limited use of personal iden- 
tifiers such as PINs, these PINs can easily be duplicated 
and/or discovered. 

[0012] Thus, a new system of conducting electronic trans- 
actions is therefore desired. Such a system should provide 
improved security that would require the use of a personal 
identifier, such as a biometric to safeguard the transactions. 

SUMMARY OF INVENTION 
[0013] In exemplary embodiments of the invention, a user 

tions. The instrument contains a digital certificate and suit- 
ably authenticates with a server on the network that conducts 
all or portions of the transaction on behalf of the user. The 
user is a purchaser conducting a purchase transaction and the 
server is a wallet server that interacts with a security server 
to provide enhanced reliability and confidence in the trans- 

[0014] Electronic transactions, such as purchase transac- 
tions, arc conducted by receiving a transaction request from 
a user; issuing a challenge to said user; receiving a response 
from said user based upon said challenge; receiving a 
biometric at a biometric sensor communicating with said 
system to initiate verification of a biometric sample; and, 
processing said response to verify an instrument and pro- 
cessing said biometric sample to verify said user. The 
biometric sample may include a user's voice, fingerprint, 
facial features, ear features, sound signature, handwriting 
signature, vascular patterns, DNA, hand geometry, smell, 
keystroke/typing features, iris, retina, and brainwaves. 

[0015] The invention also may include the steps of assem- 
bling credentials which include at least one key for the 
electronic transaction; providing at least a portion of the 
credentials to the user; receiving a second request from the 
user which includes the portion of the credentials; and 
validating the portion of the credentials with the key to 
provide access to a transaction service. 

[0016] Moreover, the present invention protects a network 
server from an attack by: restricting access to the network 
server to a portion of the network server for at least a 
selected protocol and scanning the portion of the network 
server for particular characters associated with the selected 
protocol. The particular characters may be removed or 
replaced with benign characters in order to reduce the 
security risk posed by the selected protocol. In an exemplary 
embodiment, the characters can be logged in order to form 



a security log. The security log can be reviewed to determine 
whether the particular characters are hostile . Alternatively, a 
request may be denied. 

[0017] The present invention also includes a transaction 
tool, such as a digital wallet used to perform purchase 
transactions, having an activator and a toolbar. In an exem- 
plary embodiment, the toolbar allows a user to perform a 
small download of the activator and the toolbar utilizes one 
or more operating system controls, for example, a system 
tray icon. The transaction tool also includes a form fill 
component and an auto remember component for pre-filling 
forms with information previously provided by the user. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0018] The above and other features and advantages of the 
present invention are hereinafter described in the following 
detailed description of exemplary embodiments to be read in 
conjunction with the accompanying drawing figures, 
wherein like reference numerals are used to identify the 
same or similar parts in the similar views, and: 

[0019] FIGS. 1A-C are block diagrams of various embodi- 
ments of an exemplary transaction system; 

[0020] FIG. 2 is a block diagram of an exemplary pur- 
chaser system; 

[0021] FIG. 3 is a block diagram of an exemplary security 

[0022] FIG. 4 is a block diagram of an exemplary wallet 

[0023] FIGS. 5-8 are exemplary screen displays for an 
embodiment of a digital wallet formed in accordance with 
the present invention; 

[0024] FIG. 9 is a flow diagram of an exemplary process 
executed by an exemplary activator application; 

[0025] FIG. 10 is a message sequence chart of an exem- 
plary login sequence; 

[0026] FIG. 11 is a message sequence chart of an exem- 
plary purchase sequence; 

[0027] FIG. 12A is a message sequence chart illustrating 
a potential security problem encountered with many script- 
ing languages; 

[0028] FIG. 12B is a message sequence chart of a correct 
communications flow without the security problems shown 
in FIG. 12A; 

[0029] FIG. 13 is a flow diagram of an exemplary process 
for reducing or eliminating undesired executable code; 

[0030] FIG. 14 illustrates an exemplary smartcard trans- 
action system in accordance with the present invention; 
[0031] FIG. 15 illustrates an exemplary registration pro- 
cedure in accordance with the present invention; and 
[0032] FIG. 16 illustrates an exemplary smartcard reader 
configured with a security system, wherein the security 
system incorporates one or more biometric system. 

DETAILED DESCRIPTION 

[0033] The present invention may be described herein in 
terms of functional block components and various process- 
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ing steps. It should be appreciated that such functional 
blocks may be realized by any number of hardware and/or 
software components configured to perform the specified 
functions. For example, the present invention may employ 
various integrated circuit (I.C.) components (e.g., memory 
elements, processing elements, logic elements, look-up 
tables, and the like), which may carry out a variety of 
functions under the control of one or more microprocessors 
or other control devices. Similarly, the software elements of 
the present invention may be implemented with any pro- 
gramming or scripting language such as ( .', C++, Java, 
COBOL, assembler, PERL, or the like, with the various 
algorithms being implemented with any combination ol'data 
structures, objects, processes, routines or other program- 
ming elements, further, it should be noted that the present 
invention may employ any number of conventional tech- 
niques for data transmission, signaling, data processing, 
network control, and the like. Still further, the invention 
could be used to detect or prevent security issues with a 
scripting language, such as JavaScript, VBScript or the like. 

[0034] It should be appreciated that the particular imple- 
mentations shown and described herein are illustrative of the 
invention and its best mode and are not intended to other- 
wise limit the scope of the present invention in any way. 
Indeed, for the sake of brevity, conventional data network- 
ing, application development and other functional aspects of 
the systems (and components of the individual operating 
components of the systems) may not be described in detail 
herein. Furthermore, the connecting lines shown in the 
various figures contained herein are intended to represent 
exemplary functional relationships and/or physical cou- 
plings between the various elements. It should be noted that 
many alternative or additional functional relationships or 
physical connections may be present in a practical electronic 
transaction system. 

[0035] To simplify the description of the exemplary 
embodiments, the invention is frequently described as per- 
taining to a system of electronic commerce running over the 
Internet. It will be appreciated, however, that main' appli- 
cations of the present invention could be formulated. For 
example, the system could be used to authenticate users of 
a computer system, or to activate a passcode system, or any 
other purpose. Similarly, the invention could be used in 
conjunction with any type of personal computer, network 
computer, workstation, minicomputer, mainframe, or the 
like running any operating system such as any version of 
Windows, Windows NT, Windows2000, Windows 98, Win- 
dows 95, MacOS, OS/2, BeOS, Linux, UNIX, or the like. 
Moreover, although the invention is frequently described 
herein as being implemented with TCP/IP communications 
protocols, it will be readily understood that the invention 
could also be implemented using IPX, Appletalk, IP-6, 
NetBIOS, OSI or any number of existing or future protocols. 

[0036] Furthermore, the customer and merchant may rep- 
resent individual people, entities, or business while the bank 
may represent other types of card issuing institutions, such 
as credit card companies, card sponsoring companies, or 
third party issuers under contract with financial institutions. 
The payment network includes existing proprietary net- 
works that presently accommodate transactions for credit 
cards, debit cards, and other types of financial/banking 
cards. The payment network is a closed network that is 



assumed to be secure from eavesdroppers such as the 
American Express 1 B network, VisaNet® network or Veriph- 

[0037] Additionally, other participants may be involved in 
some phases of the transaction, such as an intermediary 
settlement institution, but these participants are not shown. 
Each participant is equipped with a computing system to 
facilitate transactions. The customer has a personal com- 
puter, the merchant has a computer/server, and the bank has 
a main frame computer; however, any of the computers may 
be a mini-computer, a PC server, a network set of computers, 
laptops, notebooks, hand held computers, set-top boxes, and 
the like. 

[0038] Referring now to FIG. 1A, a transaction system 
100 suitably includes at least one user computer 110, a 
transaction authorizer computer 120, a security server 130 
and an optional transaction tool server 140. In various 
embodiments described in detail herein, the transaction 
system 100 is used in electronic commerce to conduct 
purchase transactions. Specifically, the user computer 110 is 
a purchaser or customer computer, the transaction authorizer 
computer 120 is a merchant computer and the transaction 
tool server 140 is a digital wallet server. It will be appreci- 
ated that although the transaction system described herein is 
an electronic commerce system, the present invention is 
equally applicable to various other electronic transaction 
systems. 

[0039] The various computer systems and servers are 
interconnected as appropriate by a data network 102, which 
is any data network such as the Internet or another public 
data network. Other suitable networks 102 include the 
public switched telephone network (PSTN), corporate or 
university intranets, and the like. In various embodiments, 
such as the one shown in FIG. IB, merchant computer 120 
is electronically coupled to security server 130 through a 
data connection 152 separate from network 102. Similarly, 
various embodiments include a connection 150 separate 
from network 102 connecting the wallet server 140 and 
security server 130. Exemplary data connections suitable for 
use with connections 150 and 152 include telephone con- 
nections, ISDN connections, dedicated Tl or other data 
connections, wireless connections and the like. It will be 
appreciated that connection 150 and connection 152 may be 
identical connections, or each may be an entirely different 
form of connection in various embodiments of the invention. 

[0040] Various embodiments, such as the one shown in 
FIG. 1C, also include an application server 160. In various 
embodiments, databases (not shown) and/or profile servers 
(not shown) may be connected to application server 160 
and/or wallet server 140. Application server 160 can be used 
to balance the workload. Spreading the workload between 
digital wallet 140 and application server 160 can enhance 
efficiency and/or security. For example, application server 
160 may perform some of the functionality performed by the 
Wallet server 140, such as database access. Because the 
application server 160 is not connected to the data network 
102, security may be enhanced by having database access be 
performed by the application server 160 instead of the wallet 
server 140. 

[0041] While various exemplary embodiments have been 
illustrated in FIGS. 1A-C, it will be appreciated that other 
embodiments are possible. For example, an embodiment 
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may include connection 150 but not connection 152 or vice 
versa. Furthermore, components (e.g., customer 110, mer- 
chant 120, security server 130, wallet server 140 and appli- 
cation server 160) may be individual computers or net- 
worked groups of computers acting with similar purpose to 
fulfill the functions described herein. Functionality attrib- 
uted to a single component may be distributed among one or 
more individual computers in order to fulfill the described 
functionality. For example, the wallet server 140, may in fact 
be a collection of Web servers, application servers, database 
servers and other types of servers. 

[0042] To conduct a transaction, customer 110 suitably 
establishes a connection through network 102 with a mer- 
chant 120. When a purchase is to be consummated, customer 
110 accesses wallet server 140. The customer 110 is then 
redirected to security server 130 to verify that a smartcard is 
in the customer's possession. The smartcard may include a 
digital certificate that uniquely identifies the card such that 
digital credentials relating to the transaction may be created, 
as described below. In various embodiments, portions of the 
digital credentials are returned to customer 110 and a portion 
is provided to wallet server 140 via secure connection 150. 
Customer 110 may then use the digital credentials to authen- 
ticate to a wallet server 140, which may complete the 
electronic transaction as a proxy for customer 110. Wallet 
server 140 may include functionality for completing pur- 
chase forms affiliated with merchant computer 120, for 
example. When merchant 120 receives a secure purchase 
instrument identifier from customer 110 or from wallet 
server 140, card authorization may take place over connec- 
tion 152 as with any ordinary charge card authorization. As 
described above, the communications can be performed 
using various protocols, for example SSL or VPN and the 
like. Because the smartcard contains identifying information 
that is unique to the particular card and which can be made 
known to the network through electronic means, a purchase 
transaction conducted with the smartcard is more secure 
than a transaction conducted with an ordinary charge or 
credit card. A lower discount rate may be justified for the 
secure transaction, which may be processed by the card 
issuer as a "Card Present" transaction. Additionally, if the 
transaction is a "Card Present" transaction, the risk of fraud 
may be transferred from the merchant to the card issuer. 

[0043] With reference now to FIG. 2, an exemplary pur- 
chaser computer 110 (also referred to as a client, customer, 
or user computer) is any computer system that is capable of 
initialing an electronic purchase transaction on data network 
102. In various embodiments, purchaser computer 110 is a 
personal computer running any operating system 212 such 
as any version of the Windows operating system available 
from the Microsoft Corporation (Redmond, Wash.) or any 
version of the MacOS operating system available from the 
Apple Corporation (Cupertino, Calif.). 

[0044] Purchaser computer 110 suitably includes hard- 
ware and/or software to allow a smartcard 202 to interface 
with a Web browser 216 through operating system 212. Web 
browser 216 is any program compatible with purchaser 
computer 110 that communicates via network 102 such as 
Netscape Communicator available from the Netscape Cor- 
poration (Mountain View, Calif.), Internet Explorer avail- 
able from the Microsoft Corporation (Redmond, Wash.), or 
the AOL Browser available from the America Online Cor- 
poration (Dulles, Va.). In various embodiments, purchaser 



computer 110 includes a wallet client 214, which is any 
computer program configured to communicate with wallet 
server 140. An exemplary wallet client 214 is the Microsoft 
Wallet, or the Globeset Wallet available from the Globeset 
Corporation (Austin, Tex.), although any wallet program 
could be used. 

[0045] Wallet client 214 and browser 216 may interact 
with smartcard 202 by sending data through operating 
system 212 to a card reader 204. Card reader 204 is any 
reader device capable of transferring information between 
wallet client 214 and smartcard 202. In various embodi- 
ments, card reader 204 is an ISO-7816 compatible reader 
such as the Model GCR410 available from the Gemplus 
Corporation (Redwood City, Calif.), or any other suitable 

[0046] Smartcard 202 is any card that is capable of con- 
ducting electronic transactions, such as any smartcard that is 
compatible with the following ISO standards, all incorpo- 
rated herein by reference in their entirety: 

[0047] ISO/IEC 7816-1:1998 Identification cards- 
Integrated circuit(s) cards with contacts — Part 1: 
Physical characteristics; 

[0048] ISO/IEC 7816-2:1999 Information technol- 
ogy — Identification cards — Integrated circuit(s) 
cards with contacts — Part 2: Dimensions and loca- 
tion of the contacts; 

[0049] ISO/IEC 7816-3:1997 Information technol- 
ogy — Identification cards — Integrated circuit(s) 
cards with contacts — Part 3: Electronic signals and 
transmission protocols; 

[0050] ISO/IEC 7816-4:1995 Information technol- 
ogy — Identification cards — Integrated circuit(s) 
cards with contacts — Part 4: Interindustry com- 
mands for interchange; 

[0051] ISO/IEC 7816-5:1994 Identification cards- 
Integrated circuit(s) cards with contacts — Part 5: 
Numbering system and registration procedure for 
application identifiers; 

[0052] ISO/IEC 7816-6:1996 Identification cards- 
Integrated e'ireuit(s) cards with contacts — Part 6: 
Interindustry data elements; and 

[0053] ISO/IEC 7816-7:1999 Identification cards- 
Integrated circuit(s) cards with contacts — Part 7: 
Interindustry commands for Structured Card Query 
Language (SCQL). 

[0054] An exemplary smartcard 202 is a smartcard in 
accordance with the ISO 7816 specifications including a 
model SLE66 chip available from the Infineon Corporation 
(Munich, Germany). The SLE66 chip includes a memory 
(such as a 16 k memory, although more or less memory 
could be used) and a processor running, for example, the 
Multos operating system (such as Multos v.4). In various 
embodiments smartcard 202 also includes an applet for 
storing and processing digital certificates or other crypto- 
graphic functions. For a basic introduction of cryptography, 
see "Applied Cryptography: Protocols, Algorithms, And 
Source Code In C," by Bruce Schneier and published by 
John Wiley & Sons (second edition, 1996), which is hereby 
incorporated by reference. For example, an X.509 Java 
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applet could be included on smartcard 202 for processing an 
X.509 certificate stored thereon. While the embodiments 
described herein utilize a smartcard, it will be appreciated 
that other intelligent tokens, for example a global system for 
mobile communication (GSM) mobile phone, can be sub- 
stituted for the smartcard in various embodiments of the 
invention. 

[0055] With reference now to FIG. 3, a security server 130 
suitably includes an interface to network 102, a security 
engine 304 and an authorization server 306 communicating 
with a database 310. Network interface 302 is any program 
that facilitates communications on network 102, such as a 
Web server. In various embodiments, network interface 302 
is based upon Netscape Enterprise Server, available from the 
Netscape Corporation (Mountain View, Calif.). Network 
interface 302 receives electronic messages on network 102 
and routes them to security engine 304 or authorization 
server 306 as appropriate. 

[0056] Security engine 304 and authorization server 306 
may be separated by a firewall 308. Firewall 308 is any 
hardware or software control (such as a router access con- 
trol) capable of restricting data flow between an internal and 
an external network (not shown). In various embodiments, 
security engine 304 suitably resides outside the firewall to 
administer data transfers between the security server 130 
and the customer 110 or wallet server 140. Authorization 
server 306 retains valuable confidential information such as 
database 310, which may contain a cross-reference of x.509 
certificates stored on the various smartcards 202 associated 
with the system 100. so it may be suitably maintained on an 
internal network for enhanced security. It will be understood 
that the functionality of security engine 304 and authoriza- 
tion server 306 may be suitably combined or separated in 
various ways without departing from the scope of the 
present invention. 

[0057] With reference now to FIG. 4, an exemplary wallet 
server 140 includes a network interface 402, an optional 
applet server 404 and a wallet application 406. Network 
interface 402 is any program that facilitates communications 
on network 102, such as a Web server. In various embodi- 
ments, network interface 402 is based upon Netscape Enter- 
prise Server, available from the Netscape Corporation 
(Mountain View, Calif.). Optional applet server 404 pro- 
vides server functionality for distributed programs such as 
Java programs or ActiveX controls. An exemplary applet 
server is the Java Applet Server available from Sun Micro- 
systems (Mountain View, Calif.). Applet server 404 and 
network interface 402 provide support functionality for 
wallet application 406, which may handle login functional- 
ity, retrieve wallet data from wallet database 408, and/or 
administer transactions as described herein. In various 
embodiments of the invention, wallet server 140 may 
include the SERVERWALLET (a.k.a. NETWALLET) pro- 
gram available from the Globeset Corporation (Austin, 
Tex.). 

[0058] Various embodiments of the invention may include 
an activator application that suitably helps consumers with 
the wallet purchase process. The activator application may 
present status information, for example, or may actively 
launch the wallet client 214 (FIG. 2) when appropriate. 
Additionally, the activator may maintain a local cache of 
sites supported by the wallet. 



[0059] The activator application program may be imple- 
mented as a conventional computer application. In various 
embodiments, the activator application displays information 
as a system tray icon, as a "floating bitmap," or in any other 
suitable manner. The graphical representations (e.g., icons) 
may indicate status information such as "browsing at a 
supported site,""browsing at a supported checkout page, 
""browsing at a supported payment page,""no browser win- 
dows open,""browsing at an unsupported page," and/or the 
like. 

[0060] A floating bitmap may be implemented with any 
graphical file or format, for example, a graphics interchange 
formal (GIF) file. Alternate embodiments present informa- 
tion in graphical, audio, visual, audiovisual, multimedia, 
animated or other formats. Moreover, GIF files may be 
replaced with LZW files, TIFF files, animated GIF files, 
JPEG files, MPEG files, or any other sort of graphical, audio 
or multimedia format or file. 

[0061] In an exemplary embodiment, the present invention 
is enhanced by providing a transaction tool with a window 
which includes controls which allow a user to more easily 
use the transaction tool. The transaction tool can be used for 
various electronic transactions. For example, purchase trans- 
actions, financial advisory transactions, insurance transac- 
tions, consumer-to-consumer transactions, such as barter 
transactions, transactions relating to offers and rewards, etc. 
The transaction tool described in detail herein is a digital 
wallet used for electronic purchase transactions. The digital 
wallet is enhanced by providing a window with controls for 
the customer to more easily use the wallet. In an exemplary 
embodiment, the present invention includes a client-side 
implementation for accessing digital wallet functionality 
("acli\ ator") and a server-side toolbar thai allows the user to 
perform a small download of the activator and utilize one or 
more control elements of the Operating System User Inter- 
face, for example, a Microsoft Windows system tray icon. 

[0062] The activator is object code that runs on the user's 
computer and contains routines for accessing the wallet 
server. The activator can generate events and the activator 
contains procedural logic which allows for communication 
with the wallet server in response to specific user and system 
actions or events. In an exemplary embodiment, the activa- 
tor presents a single graphical clement, lor example an icon 
which in a Microsoft Windows embodiment appears as a 
Windows system tray icon, and which enables the user to 
trigger the appearance of the wallet toolbar. In various 
embodiments, the wallet toolbar is, in effect, a special 
browser window that accesses the wallet server. The acti- 
vator communicates with the wallet server to automate the 
update of the activator object code, via a small download. In 
an exemplary embodiment, the user is queried for a confir- 
mation prior to performing the activator download. In vari- 
ous embodiments, the activator communicates with appli- 
cations other than the wallet, for example, offers of rewards. 

[0063] The system provides the content of relevant options 
on each of its web pages, namely dynamic and contextual 
information that is specific to each page viewed by the user. 
This is accomplished by the activator monitoring URLs and 
potentially keying on pages so that the user can be made 
aware of potential opportunities. For example, the activator 
can check to see if the user is viewing a merchant site and 
present applicable offers (e.g., discount on merchandise, 
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etc.) to the user. The activator can also monitor versions of 
software on the user's system and inform the user of possible 
upgrade versions. In an exemplary embodiment, the system 
is implemented on any network, such as a WAN, LAN, 
Internet, or on any personal computer, wireless electronic 
device or any other similar device. The system can be 
implemented on an operating system, for example Microsoft 
Windows, Mac OS, Linux, Windows CE, Palm OS, and 

[0064] The activator, which may be implemented on the 
client side, allows the user 110 to be in constant or inter- 
mittent communication with the digital wallet 140 issuer, for 
example, American Express, without having to have intru- 
sive windows taking up space on the user's display. As 
described above, this allows the wallet issuer to monitor and 
present possible items of interest to the user at appropriate 
times. The configurable controls presented in the window 
allow the customer to quickly navigate to desired Web sites, 
and to immediately invoke desired functionality such as 
digital shopping cart checkout. In an exemplary embodi- 
ment, the client toolbar may be a discrete window that 
associates with the user's browser window, and maintains a 
geometry that effectively renders it a part of the user's 
browser. Although when the user clicks on its controls, the 
window remains in its original state, namely the window 
directs the browser window to visit desired URLs and 
invoke specific actions (such as, use of the digital wallet). 
For example, after selecting a digital wallet icon from the 
system tray, the digital wallet toolbar 502 is displayed as a 
discrete window that is associated with the user's browser 
window 500 as shown in FIG. 5. In an alternative embodi- 
ment, the client toolbar frames the existing wallet window, 
providing the additional controls as described above in an 
extension of the window area which is provided by an 
existing wallet. In another alternative embodiment, the area 
is divided in the user's standard browser window lo create 
an area that can be used for wallet and the other controls 
described above. 

[0065] The system may be configured to provide a con- 
venient way for customers to not only visit favorite URLs, 
but also to invoke specific functionality that might otherwise 
incur many steps, and which might change as the vendors' 
sites are continually updated. The system also may provide 
a simpler user experience by making the wallet and e-com- 
merce sites not only easy to use, but by making the wallet 
and client toolbar easy to find. When a user has many 
different windows open, finding the wallet window can be 
difficult and annoying, especially as different browser win- 
dows seize GUI focus during the course of normal naviga- 
tion and interaction with sites. As such, use of the system 
tray icon and server side functionality provides a superior 
user experience. In an exemplary embodiment, the present 
system works with any known in the art browser, such as 
Netscape Navigator. 

[0066] While prior art systems may simply provide a 
customizable portal (e.g., MyAmericanExpress.com) that 
allows a user to visit the page and then traverse links from 
that page, an exemplary embodiment of the present inven- 
tion suitably provides a window with controls that will stay 
on the users' desktop as they navigate throughout the Web. 
Additionally, the client toolbar provides a means of auto- 
mating actions for the user, where these actions take place on 
third party e-commerce sites. Moreover, prior art systems 



may utilize a separate browser window to render the wallet 
controls, but the present invention utilizes a standard 
browser window which has been divided to provide an area 
for the wallet to occupy. For example, In an exemplary 
embodiment, a digital wallet icon is available to the user as 
a system tray icon (not shown). Upon invocation of the 
digital wallet icon, the digital wallet toolbar 502 is displayed 
as shown in FIG. 5. The digital wallet toolbar is unobtrusive 
while including controls which allow the user to utilize the 
digital wallet. In an exemplary embodiment, the toolbar 502 
is associated with the browser window 500. 

[0067] As shown in FIG. 6, if the user selects a shopping 
directory button from the toolbar 502, the toolbar expands to 
a shopping directory page 602. The user can select a 
merchant from the list of merchants 604 displayed in the 
shopping directory page 602. Upon selecting a merchant 
from the list of merchants 604, the digital wallet takes the 
user to the selected merchant site 702, such as is shown in 
FIG. 7. In an exemplary embodiment, when the digital 
wallet takes a user to a merchant site 702, the toolbar 502 
returns to its normal size. 

[0068] When the user makes a purchase from a merchant, 
for example by placing items in a shopping cart and pro- 
ceeding to checkout at the merchant's site, the checkout 
function is performed, in part, by the digital wallet of the 
present invention. As shown in FIG. 8, when the user 
indicates a desired purchase at a merchant site 702, the 
checkout user interface 802 of the digital wallet is displayed. 
For example, the checkout display 802 appears in one side 
of the browser window, while the merchant window 702 is 
still displayed on the opposite side of the browser window. 
Much of the information that a user would normally have to 
enter at the merchant checkout (for example, name, address, 
e-mail address, credit card information, etc.) is already 
known by the digital wallet and is pre-filled in the digital 
wallet checkout window 802. In an exemplary embodiment, 
the user can edit the pre-filled information. 

[0069] In an exemplary embodiment, the present system 
also includes methods and apparatus that facilitate the 
reliable population of HTML forms on Web sites. The end 
result is that users can identify information content that they 
wish to provide to sites in a general manner, independent of 
the actual appearance, labeling, and behaviors of various 
e-commerce Web sites. In an exemplary embodiment, the 
present invention includes an "auto-remember" component 
that allows a user to capture data that is entered and a "form 
fill" component which includes a powerful set of processes 
that results from the combination of several different models 
of sites and users. 

[0070] The present invention collects information from 
users, storing it securely and reliably on a server, and then 
provides it to appropriate form fields under the user's 
direction. The system maintains mappings of user informa- 
tion to the various HTML form fields of sites that are of 
interest to the user. This information can then direct how 
HTML forms are to be filled (or pre-filled) for users who 
wish to interact with those sites. 

[0071] With respect to the "auto-remember" feature, prior 
art digital wallets may implement a remember function, but 
it must be initiated by the user. With the present 'auto- 
remember" feature, digital wallet users do not need to click 
a button to remember the form they just filled out because 
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the present system remembers the fields that the user is 
submitting on a merchant window. When a form is submit- 
ted (for example, by pressing a "Submit" button or a "Buy" 
button), the online wallet responds by determining if the 
window that triggered the form submission is a merchant 
window of interest. If so, the wallet suitably remembers the 
data; otherwise, the wallet can disregard the occurrence of 
the form submission and continue to run as normal. 

[0072] The digital wallet controls may include a button 
labeled "remember," or may also support an automatic 
remember feature that is always active. In general, fields 
other than those that are automatically populated by the 
wallet can be remembered. In this context, remembering a 
field means that when a user enters data into a specific field, 
the value will be stored by the system. The w allet component 
will detect field values entered in this way, and will securely 
transmit them to a server via the Internet. When a user next 
goes to this page, the wallet, in addition to populating the 
form with fields that are retrieved from the wallet system, 
will also populate the form with values that had previously 
been remembered. When processing the form (pre-fill), the 
wallet will securely retrieve field values from the server. 

[0073] More particularly, with respect to the Internet 
Explorer browser, the invention suitably implements an 
ActiveX control that attaches itself to a Web page such as, 
for example, the American Express Online Wallet. In an 
exemplary embodiment, the ActiveX control contains a 
method that captures the browser events of all Internet 
Explorer browsers, so that the American Express Online 
Wallet can respond to these events if necessary by a Java- 
Script function loaded within the American Express Online 
Wallet, thereby allowing the system to obtain the completely 
downloaded document within an Internet Explorer browser. 
Specifically, this allows the system to capture the "Docu- 
ment Complete" event raised by the Internet Explorer 
browser which specifies when a document has finished 
loading. When this event is captured, the ActiveX control 
notifies the American Express Online Wallet by calling a 
JavaScript function loaded within the American Express 
Online Wallet. This function responds to this event by 
suitably communicating with the ActiveX control to capture 
the "Form Submit" events for all forms on all Internet 
Explorer browsers. 

[0074] When a user fills a form on a Web page and clicks 
the "Submit" (i.e., any control, such as a button, that submits 
a form) button for that page, the American Express Online 
Wallet is notified by the ActiveX control calling a JavaScript 
function loaded within the American Express Online Wallet. 
The American Express Online Wallet then suitably deter- 
mines if the document raising the "Submit" event is of 
interest by checking the URL of the window that raised the 
event. If the event is to be handled, the American Express 
Online Wallet must call a suitable function within the 
ActiveX control that obtains the document object model 
(DOM) that raised the event. The DOM can then be tra- 
versed and the form values can be saved so that they can be 
sent to the server for storage in memory. In an exemplary 
embodiment, the ActiveX control must properly detach itself 
from capturing the browser events and form "Submit" 
events so that runtime errors are minimized. 

[0075] With respect to the Netscape browser, because of 
Netscape's implementation of events, the system captures 



the event from within JavaScript alone. If the system suc- 
cessfully obtains the "Universal Browser Write" privilege 
(i.e. granted by the user), the system can then successfully 
call a function that allows an external window to capture 
events of another window. The system then can traverse the 
document object model for all frames of that window. When 
doing so, the system notifies each form of the window that 
the system wants to capture the "Submit" event. As such, 
when a user fills a form on the window that the system 
notified and clicks the "Submit" button (i.e., any control, 
such as a button, that submits a form) for that page, the 
online wallet is notified and suitably responds. One skilled 
in the art will appreciate that the present invention may be 
implemented in any suitable transaction system, including, 
but not limited to any suitable digital wallet system. 
[0076] With respect to the form fill function, the digital 
wallet, such as, for example, the American Express Online 
Wallet, provides a form fill functionality to aid users in 
populating forms. Prior art systems, such as the system 
provided by GlobeSet, Inc., typically use a Browser Helper 
Object (BHO). The BHO approach often includes disadvan- 
tages such as, for example, the Internet Explorer 5.0 browser 
has a bug where it will only load the first BHO specified in 
the registry. This is a problem for any application since it 
cannot be sure whether its BHO is loaded or not. Moreover, 
a BHO is loaded for each instance of Internet Explorer such 
that multiple instances of a BHO could be running at any 
given time — therefore eating up memory and slowing down 
navigation for all browsers versus only the one of interest. 

[0077] The present invention may be configured to replace 
the BHO solution by using the same ActiveX control as 
specified in the "auto remember" feature. By attaching an 
ActiveX control to the Online Wallet Web page, the system 
suitably obtains the document object model for any docu- 
ment loaded within any given Internet Explorer browser by 
using, for example, the Shell Windows API. When a user 
clicks a "Fill Form" button on the Online Wallet, the wallet 
can respond by first obtaining the document object model 
through the ActiveX control. Next, the wallet can save the 
names of the fields that make up forms and send them to a 
heuristic engine on the server. The server will respond to this 
request by returning the values that should be used to fill 
these fields. The fields can then be filled using the same 
document object model obtained earlier. As such, the present 
invention reduces the problem of having to enter repetitive 
data in forms at Web sites. In addition to saving effort on part 
of customers, it increases accuracy of the entered data. 

[0078] More particularly, the architecture of the present 
invention combines a server-side model of each site (e.g., 
fields, pages, links, etc.), server-side model of user (e.g., 
profile), user generated model of site (e.g., macro recording, 
tagging, drag and drop) model of site manually generated by 
system (e.g., to augment and validate the user generated 
models), and heuristically generated model of site (e.g., 
inference of semantic information about fields, actions, etc.). 
The present system creates and stores several distinct types 
of models. The first characterizes the site, for example, how 
do you check out, how do you add something to a shopping 
cart, how do you search for a type of product, how do you 
enter preferences (e.g., travel), etc. The second model char- 
acterizes the user, for example, what are the things that a 
user can do and what are the profile attributes of a user. By 
combining these two models, the present system creates 
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special processes that add great flexibility and power. The 
system maps from the model of what a user can do, to the 
model of the site, wherein the site models are generated by 
any known method. As such, the site model can be created 
by the user, by the host, by the transaction card company 
(issuer) or even by the site provider. In an exemplary 
embodiment, ECML/XML can be used to represent models 
for the site. In various embodiments site models can be 
exchanged with other systems. 

[0079] For example, a user may routinely visit sites of 
different airlines and travel services in order to purchase 
airline tickets. Each site typically has fields on different 
screens for collecting information that are relatively similar 
between the various sites. However, each site will use 
different II I MI. form fields that arc placed on different 
URLs, and which may also change over time. Even though 
the information is very similar in nature across the different 
sites, there is presently no common mechanism to automate 
the process of populating fields for user travel preferences 
(e.g., seating, meals, travel times, affinity rewards, etc.). 
Each site may have its own profile of the user which stores 
much of this information. However, the user would still need 
to create such a profile for each site independently, given the 

[0080] The present invention includes heuristics based 
field recognition. In this approach, field labels art identified 
by their spatial proximity to form fields of interest. A 
combination of field labels and form field HTML attributes 
(most notably the "name" attribute of the HTML "input, 
""select," and "action" elements) will be used as input to a 
heuristic engine that contains a dictionary to aid the identi- 
fication of desired fields. 

[0081] In another embodiment, the present invention 
includes user mediated field recognition. In this approach, 
the user willfully captures input via a "Remember" button or 
similar control that allows servers to capture information 
about the sequence of actions the user executes. When the 
user does this, he or she can effectively "play back" the 
actions (similar to macro scripting employed in other soft- 
ware systems). As such, the user's actions can be fed into the 
heuristic engine and also be fed directly into field mapping 
tables that are used by the processes of this engine. 

[0082] In an exemplary embodiment, the above two 
approaches may need some manual interaction in order to 
completely create process maps and form field maps that 
accurately depict the navigation and form field completion 
possibilities that enable this invention. When necessary, 
human analysts will operate in a fashion similar to what 
occurs during user mediated field recognition, although they 
will provide far more information about their navigation and 
form filling processes than would the typical user. In all 
cases, the information that is gathered is used to create a 
process map (or detailed site map) that depicts the sequence 
of actions (form fill, HTTP Post, HTTP Get, etc.) by which 
various activities can occur. A field map will also be gen- 
erated for each of the Web pages in the process map, wherein 
the field map defines the precise names of fields that can be 
used to automate form submission. State maps may also be 
required to track the states of users as they interact with the 
Web site (the state of the user, such as logged on versus not 
logged on, will modify the results of specific actions on the 
site). 



[0083] In an exemplary embodiment, the process by which 
the user interacts can either be fully automated (in which 
case the user merely conveys the desire to perform a scripted 
action) or can be user mediated (in which case the invention 
can pre -fill form fields for the user, thereby affording the 
user the opportunity to correct, change, or complete any 
fields that require further data entry). In addition to the 
products and services described above, the enabling tech- 
nology in the form of the process and field maps can be 
leveraged for new products and services, such as enabling 
companies to automate the entry of form data for their site 
visitors. For example, if a company compiled process and 
field maps for the benefit of their own customers (by any of 
the means described above), then the company can also 
license this information, services, and products to third-party 
customers. The sites for which these maps exist may also use 
the present invention such that the sites benefit by delivering 
a similar service to their customers who are not benefiting 
from the system. The underlying processes themselves will 
also rely on a system which acquires this information and 
reformats it, for example, as XML and ECML. These 
standard representations would form the basis of informa- 
tion exchange for the latter two products or services. 

[0084] With reference now to FIG. 9, a process 900 
implemented by an exemplary activator program suitably 
includes initializing the application (step 902), monitoring 
the uniform resource locator (URL) as the user browses or 
shops online (step 904), determining whether the user is 
browsing at a supported site (step 906), determining the type 
of supported site (steps 90S and 912) and responding appro- 
priately at processing steps 910 and 914 (respectively). 
Other features (such as coupons, special offers, monitoring, 
security and the like) may be implemented at step 916. 

[0085] Initialization step 902 suitably involves opening 
the activator application and initializing the application as 
appropriate. The activator application may be initialized in 
response to system startup, connection to a network (such as 
the internet or a LAN), or initialization of a browser (such 
as Internet Explorer, available from the Microsoft Corpora- 
tion (Redmond, Wash.) or Netscape Explorer, available from 
the Netscape Corporation (Mountain View, Calif.). In vari- 
ous embodiments, the activator application may contact the 
wallet server 140 (FIG. 1), wallet application 406 (FIG. 4) 
or another server on network 102. The activator application 
suitably contacts the remote server to obtain information 
such as a list of Web sites, domain names, or URLs that are 
supported by the wallet. This information may he obtained 
on a regular basis (e.g. daily, weekly, monthly, or at each 
initialization of the agent application) or when polled by the 
activator application or the server. In various embodiments, 
the activator application stores the list of supported URLs in 
a cache or file on a local drive, or in memory on the client 
computer. 

[0086] As the user browses the Internet or other data 
network 102, the activator application suitably monitors the 
location of the user on the network. One method of moni- 
toring the user's browsing is to monitor the URL used by the 
user's browser. In such embodiments, the activator applica- 
tion obtains the present URL from the user's browser (or 
from the system network interface, as appropriate) and 
compares (step 906) the present URL against the list of 
supported URLs obtained from the remote server in initial- 
ization (step 902). These comparisons are shown in logically 
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separate steps 906, 908, 912 and 916 in FIG. 9, although 
these steps could be combined or separated in any fashion 
without departing from the ambit of the invention. For 
example, although FIG. 9 shows multiple comparisons 
being executed, a single comparison of each present URL 
against the list of supported URLs may be sufficient in 
certain embodiments. 

[0087] If the present URL corresponds to a supported 
URL, the activator application responds appropriately, for 
example, if the present URL is a supported checkout page 
(yes in step 908), the activator application executes a check- 
out process (step 910). The checkout process may include 
notifying the user that the checkout page is supported 
through a pop-up message, or by displaying a particular icon 
in the system tray or in the floating window. If the wallet 
client application 214 is not already open, the activator 
application may present a dialog box or other prompt to the 
user indicating that the page is supported by the wallet 
application 214. The prompt may also provide a button or 
other mechanism by which the user may open the wallet 
application 214. 

[0088] If the present URL corresponds to a supported 
payment page (yes in step 912), the activator application 
may provide payment instructions to the wallet application, 
or otherwise pass control to the wallet application (step 914). 
Messages sent between the activator application, the wallet 

messages, object routine calls, OS calls, or the like. 
[0089] In various embodiments, the functionality 
described above is accomplished using cookies as described 
next. Cookies are used to detect a valid user context. If a 
valid user context is detected, the activator will either: 
launch a server application or launch a server toolbar that 
enables the user to launch other applications. For example, 
a user's browser might have several cookies that signify the 
ability to purchase via either a private payment or a specific 
card product. The activator may launch a toolbar that allows 
the user to select a desired payment instrument (e.g., from 
private payments or a card in the user's digital wallet). It will 
be appreciated that the available applications are not all 
necessarily related to a purchase transaction. In various 
embodiments, the context information is stored both on a 
server and in cookies associated with the browser. For 
example, the cookies might act as a key by which the context 
information can be retrieved from the server. 
[0090] Other functionality (step 916) may also be incor- 
porated into the activator application, for example, security 
mechanisms (such as those described above and below), 
customer monitoring functions, coupons, special offers and 
the like could be implemented. In the case of coupons or 
special offers, the activator could sense the present URL as 
corresponding to a particular product or Web page. When the 
user "surfs" or browses to the particular supported URL, the 
activator application notices the match and presents the user 
(via a dialog window or via the browser, or the like) with a 
special offer, such as an opportunity to purchase a particular 
product or to receive a special discount on a purchase. It will 
be appreciated that other functionality could be incorporated 
into the activator application without departing from the 
ambit of the present application. 

[0091] In various embodiments of the invention, wallet 
client 214 (FIG. 2) is pre-filled with information that is 



specific to the particular user/customer. With reference to 
FIG. 1, a user may apply for a digital wallet by contacting 
a Web server such as wallet server 140 on network 102. The 
user completes a registration form (which may be generated 
with CGI scripts, for example) to apply for the wallet. Wallet 
server 140 suitably receives demographic, account and other 
information (e.g. address, shipping address, name, credit 
card number, and the like) from authentication server 306 
(FIG. 3) or another server on a private network. This 
information may be used to configure a wallet client 214 
(FIG. 2) that is unique to the particular user. One method of 
configuring the wallet client 214 is to create a configuration 
file that is associated with client 214 and that is read by client 
214 to obtain wallet information as described above. 
[0092] In an exemplary embodiment, the registration 
information also includes card reader information which 
includes whether the card reader port should be serial or 
USB port. If the wallet application is approved, a card reader 
may be shipped or otherwise provided to the user, and a 
special code (such as a cryptographic key, or a password, or 
any other sort of electronic or printed code) is also provided 
to the user. The user then registers for online wallet service 
by electronically contacting wallet server 140 and authen- 
ticating to the server with the card and/or with the special 
code. After providing the special code, the user receives a 
specially configured copy of the wallet software, which may 
be installed on customer computer 110, as appropriate. The 
wallet pre-fill procedure may be used with any credit card or 
charge card by simply associating a version of the wallet 
program with a special code. Configuration information for 
a particular user is associated with a code that is provided to 
the user, who may later present the special code to authen- 
ticate him/herself with wallet server 140 to obtain a copy of 
the wallet that has already been pre-configured with data 
specific to the particular user. 

[0093] With primary reference now to FIGS. 1 and 10, 

wallet server 140 using smartcard 202. To log fn fcfthe wallet 
server 140, customer 110 first may connect to the security 
server 130 via browser 216. The user selects a particular 
uniform resource locator (URL) for the login page through 
a bookmark, an internet shortcut, a hyperlink, or any other 
suitable technique. Security server 130 may then return a 
login page via network interface 302. In various embodi- 
ments, a form entry and submission button for user/pass- 
word login and a hypertext link for smartcard login are 
provided as part of the login page. The user selects smartcard 
login, and browser 216 suitably responds by forwarding log 
on request message 1002 (FIG. 10). Security server 130 
receives logon request 1002 and initiates the smartcard 
logon process as appropriate. In various embodiments, secu- 
rity server 130 formats a cryptographic challenge by autho- 
rization server 306 or security engine 304 in response to 
logon request message 1002. Cryptographic challenge 1004 
is any sort of challenge message that prevents replay attacks 
(e.g., fraudulent messages created by re-sending previously 
sent authentication packets), such as a challenge that is 
based upon random data and is designed to solicit a response 
from the X.509 application stored on smartcard 202. The 
challenge is then suitably provided to customer 110 via 
network 102 as challenge message 1004. 

[0094] Upon receipt of challenge message 1004, browser 
216 suitably passes message 1004 to wallet client 214 for 
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processing with smartcard 202. If wallet client 214 is not 
running, browser 216 may automatically open the program. 
Wallet client 214 then prepares the signature response, as 
appropriate. For example, wallet client 214 may extract the 
server challenge information, format a new client challenge 
(i.e., a second cryptographic challenge for smartcard 202), 
combine both challenges into a dual challenge, and compute 
a hash of the dual challenge for later use, for example, in a 
Public-Key Cryptography System 1 (PKCS1) cryptographic 
block. The hash may be computed according to any algo- 
rithm such as MD3 or MD4, for example, and is suitably 
used to guarantee the completeness and accuracy of the data 
in the dual challenge block. It will be understood that 
PKCS1 is a public key cryptography standard defining 
mechanisms for encrypting and signing data using RSA 
public -key cryptosystems. The PKCS standard is fully 
defined in PKCS #1: RSA Cryptography Specifications 
Version 2.0 dated September 199N (available online from 
http://www.rsa.com/rsalabs/pubs/PKCS/html/pkcs-l.html) 
and incorporated herein by referenced in its entirety. 

[0095] The PKCS 1 block is suitably provided to smartcard 
202 via reader 204 for processing (step 1006 in FIG. 10). In 
various embodiments, card reader 204 interacts with cus- 
tomer computer 110 to prompt the user for a personal 
identifier, for example a personal identification number 
(PIN) or other unique identifier, to access the card. In an 
exemplary embodiment, a PIN is stored on smartcard 202. 
Alternatively, a PIN or other personal identifier may be 
stored elsewhere on the system, for example, on the reader 
204 or the customer computer 110. The user suitably enters 
the personal identifier as appropriate to unlock smartcard 
202, which receives the dual challenge block from wallet 
client 214 and digitally signs the block as appropriate. In 
various embodiments, smartcard 202 contains a private key 
that is used to compute a digital signature of the block. The 
signed block is then returned to wallet client 214, as appro- 
priate. In various embodiments, smartcard 202 also provides 
a certificate (such as an X.509 certificate) that corresponds 
to the private key used to compute the digital signature. 

[0096] After receiving the signature and certificate from 
smartcard 202, wallet client 214 suitably creates an appro- 
priate response message 1008 to be sent to security server 
130. Although response message 1008 may be in any format, 
various embodiments format response message 1008 as a 
PKCS7 message as defined in PKCS #7: Cryptographic 
Message Syntax Standard, An RSA Laboratories Technical 
Note, Version 1.5, Revised Nov. 1, 1993, available online 
from ftp://ftp.rsa.com/pub pkes doc pkcs-7.doc and incor- 
porated herein by reference in its entirety. 

[0097] After receiving response message 1008, security 
server 130 processes the message as appropriate (step 1010 
in FIG. 10). In various embodiments, response message 
1008 is routed to authorization server 306, which verifies the 
certificate and signature provided by smartcard 202. Upon 
successful verification of the certification and validation of 
the signature, in various embodiments a security token may 
be generated and returned to the customer 110 or smartcard 
202. 

[0098] In this manner, subsequent presentation of the 
Security token provides a means for the user to establish 
identity and securely interact with the wallet server. In 
various embodiments, authorization server 306 may also 



create an additional security token that identifies the user. In 
various embodiments this token may consist of multiple 
portions which can then map to an appropriate digital 
certificate, smart card, or other data, possibly utilizing data 
in database 310. In various embodiments, the additional 
security token and or portions therein may be provided to 
customer 110 in conjunction with redirect message 1012. In 
various embodiments, the additional security token may be 
provided to the customer or maintained on authorization 
server 306. 

[0099] Upon receipt of redirect message 1012, customer 
110 suitably contacts wallet server 140 to request a connec- 
tion. In various embodiments "Request connect" message 
1014 suitably includes the security token and possibly the 
additional security token in entirety or part as part of redirect 
message 1012. Wallet server 140 queries the security server 
130 using some combination of security tokens in whole or 
part to obtain identification of customer 110. The query 1016 
and response 1018 are suitably transmitted across network 
150, which in some embodiments is maintained separate 
from network 102 to enhance the security of the system 100. 
An alternative embodiment employs network 102 that in 
some embodiments affords enhanced security by Virtual 
Private Network, SSL protocol, use of shared secrets, and/or 
other cryptographic means. If the return credentials 1018 are 
in order, wallet server 140 retrieves the attributes corre- 
sponding to customer 110 from wallet database 408 and 
notifies customer 110 of a successful login via message 
1020. It will be appreciated that alternate embodiments of a 
logon sequence are possible. It will also be appreciated that 
any sort of encryption schemes, message formats and the 
like could be used to implement a login sequence 1000. 

[0100] Referring now to FIG. 11, an exemplary authenti- 
cation flow 1100 suitable for use during a purchase trans- 
action begins with a customer 110 placing a request 1102 
with wallet server 140 for an event (such as a purchase) for 
which authentication is required. Wallet server 140 suitably 
recognizes the event and submits a request message 1104 to 
the security server 130, for example, via communication 
channel 150, to format a challenge message. Authentication 
server 306 (or some other component of security server 130, 
as appropriate) then formats a challenge message 1106 
(which may include random data) and provides the chal- 
lenge message 1106 to wallet server 140, for example, via 
connection 150. Wallet server 140 receives the challenge 
message 1106 and forwards the challenge data to browser 
216 as signature request message 1108. Browser 216 opens 
wallet client 214, if necessary, and forwards signature 
request message 1108. As described above, wallet client 214 
formats a signature request block such as a PKCS1 block 
including a server challenge, a client challenge and a hash. 
The resultant signature request block is provided to smart- 
card 202 via reader 204. Smartcard 202 suitably signs the 
block and provides a copy of its X.509 certificate, as 
appropriate. 

[0101] The signed block may then be returned to wallet 
client 214, which suitably formats an appropriate signature 
response message 1110 (such as a PKCS7 message) and 
sends it to wallet server 140. Wallet server 140 then formu- 
lates validity check message 1112, which includes data from 
signature response message 1110 and the security token 
associated with customer 110 during the logon process (such 
as the exemplary logon process shown in FIG. 10). In 
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alternate embodiments, the security token provided is 
received from customer 110 as part of signature response 
message 1110. Validity check message 1112 is sent to 
security server 130 via connection 150, as appropriate. 
Security server 130 may then route validity check message 
to authorization server 306, as appropriate, which may check 
the signature and retrieve the appropriate security token 
from database 310 (step 1114 in FIG. 11). The security token 
and/or optional unique identification code retrieved from the 
database is then compared to the security token or ID 
received from the wallet server 140. If the two objects (e.g., 
security tokens or IDs) match, it can be deduced that the card 
presently used by customer 110 is the same card used by 
customer 110 at the time of log on. An appropriate approve 
or reject message 1116 is then sent from security server 130 
to wallet server 140, and the transaction is allowed to 
proceed. 

[0102] In various embodiments, wallet server 140 acts as 
a proxy lor customer 110 during transactions, for example, 
wallet server 140 may complete purchase forms including 
shipping address, card number, and the like on behalf of 
purchaser 110. Merchant 120 may then authorize the pur- 
chase transaction as a standard charge card transaction using 
conventional hardware and software. It will be realized, 
however, that the added security provided by the systems 
disclosed herein will allow added confidence in the identity 
of the purchaser, tints justifying a low er discount rate for the 

[0103] Various embodiments of the invention incorporate 
an added protection against security breaches. Because 
many server-side functions incorporated into security server 
130 or wallet server 140, for example, may incorporate 
various scripting components written in scripting languages 
such as JavaScript (as defined by Sun Microsystems, Moun- 
tain View, Calif.) or VBscript (as defined by the Microsoft 
Corporation, Redmond, Wash.), servers coupled to network 
102 may provide various functionality to the multiple clients 
110 through such server languages by providing scripts (or 
code) from the server to the client. The code is interpreted, 
compiled or otherwise executed by client computer 110. In 
embodiments incorporating JavaScript, for example, scripts 
are interpreted and executed by a browser program (e.g. 
Internet Explorer, Netscape Communicator or the like) run- 
ning on client computer 110. Other embodiments include 
other non-PC browsers, for example Wireless Application 
Protocol (WAP) phones that support Wireless Markup Lan- 
guage (WML) scripts. The various scripting languages may 
contain instructions, objects or other data mechanisms for 
accessing files on the user's hard drive, for example, or for 
otherwise manipulating data on the user's computer. To 
prevent unauthorized sources from providing executable 
code to the user, the scripting languages may include a 
mechanism for allowing the user to approve scripts provided 
only from trusted sources. For example, a user conducting 
an electronic transaction as described above may allow 
scripts provided from the wallet server to execute, but may 
prevent other scripts provided by other sources from execut- 
ing on the user's computer. 

[0104] A potential security problem encountered with 
many scripting languages is shown in FIG. 12A. An unscru- 
pulous "cracker" may create a Web site 1204 that is designed 
to perform malicious activities against users of a legitimate 
Web server 1206. The cracker site 1204 (shown as the 



"criminal site" in the figure) may, for example, provide a 
portion of code, such as a script, to the user. The criminal site 
1204 may also induce the user's Web browser 216 to request 
a particular uniform resource locator (URL) at the legitimate 
server 1206 (such as the wallet server 140, or any other 
server on network 102). The referenced URL may be delib- 
erately crafted such that the legitimate server 1206 returns, 
for example, an error message or other response to the client 
browser 216. In various embodiments, the response from the 
legitimate server 1206 may automatically include a portion 
or variation of the request from the user's Web browser 216. 
If that response includes JavaScript, VBscript or other code 
generated as a result of the malicious intent of the criminal 
site 1204, then the code may be executed on the user's 
computer. This example illustrates one of many techniques 
in which a "cracker" may induce a legitimate Web server 
1206 to send malicious instructions to a user's Web browser 
216. Because the various coding and scripting languages 
contain instnictions for accessing the host computer's file 
system, registry, or the like, it will be understood that the 
unauthorized execution of such code is highly undesirable. 
Nevertheless, the technique shown in FIG. 12A may allow 
scripting or other code from a criminal site 1204 to be 
provided to a user's computer. Because the user's computer 
thinks that the scripting came from a trusted source (i.e. the 
wallet server), the client's computer may execute the code 
from the criminal site, thus creating the potential for dam- 
age, unauthorized data dissemination or destruction, or the 
like. IKi. 1215 illustrates the correct communication How 
that should occur (as opposed to the criminal attack flow 
shown in FIG. 12A). 

[0105] To prevent this potential security problem, various 
embodiments of the invention suitably include techniques 
for reducing or eliminating undesired executable code. With 
reference to FIG. 13, a process 1300 for reducing the 
likelihood of script attacks suitably includes the steps of 
limiting the portions of the server having elevated permis- 
sion (step 1302), removing dangerous characters within that 
portion of the site (step 1304), encoding certain characters 
where necessary (step 1306), and optionally logging data 
that is provided to users from the relevant portion of the Web 
site (step 1308). 

[0106] With regard to step 1302, a Web site typically 
includes various pages, each page having a unique URL. 
Users of the site may place elevated trust in certain servers 
(such as those corresponding to financial institutions or 
merchants who are reputable). By restricting the elevated 
trust to only a portion of the Web site (e.g., a limited subset 
of URLs corresponding to the trusted Web site), the level of 
trust afforded to the rest of the site is suitably reduced and 
security is enhanced. Trust may be restricted to a limited 
portion of the site by configuring the user's Web browser to 
trust only a portion of the site, for example. The user's Web 
browser may be configured manually or by a configuration 
script provided by a wallet server, for example. When only 
certain pages (e.g. a portion) of the Web site are enabled with 
heightened trust, any scripts included in references to other 
pages will either not be executed or will not be executed 
with heightened trust. 

[0107] In addition to (or as an alternative to) configuring 
the client such that the client only "trusts" a certain portion 
of the server, the server may be configured to improve the 
security of the client-server interaction. For example, script- 
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ing with heightened trust may be disallowed on most of the 
server to improve security. Moreover, data provided to the 
trusted portion of the Web site may be monitored and/or 
modified before being returned to the user (steps 1304 and 
1306). Most scripting languages require certain characters 
for formatting commands, f ur example, the JavaScript lan- 
guage is frequently encoded with script instructions placed 
between angle brackets ("•<" and ">"). Hence, the angle 
brackets may be removed from any content that will be 
returned by a trusted portion of the Web site. If a Web page 
provided from a trusted portion of the Web site were to 
include a "criminal" JavaScript program attempting to use 
angle brackets, for example, the script instructions would 
not execute on the user's computer because the script 
instructions would not be properly formatted after removing 
the angle brackets. Alternatively, certain "dangerous" char- 
acters (such as the angle brackets in JavaScript) may be 
returned in an alternate format, for example, in "ampersand 
notation" with an ampersand ("&") and an American Stan- 
dard Code for Information Interchange (ASCII) value for the 
particular character, or by replacing the "dangerous" char- 
acter with a safe character, such as the "space" character 
(step 1306). It will be appreciated that any characters could 
be eliminated or encoded in various embodiments of the 
invention depending upon the particular languages, scripting 
environments, and the like that may be utilized. 
[0108] In various embodiments, an optional step 130,8 
suitably includes maintaining a data log of information 
provided by the various portions of the Web site. All content 
in which characters have been encoded or removed can be 
logged so that the log can be reviewed to determine if the 
Web site is being used to compromise a network client. For 
example, all content provided from the Web page, all content 
provided from within the trusted portion, all content having 
scripting/programming content, all content from outside the 
trusted portion, or any other part of the Web site content 
could be logged into one or more data files. The data files 
may be suitably searched or otherwise consulted to deter- 
mine whether there have been attempts to provide unautho- 
rized content to users by the server. 

[0109] In some cases internal machines can be attacked by 
a "criminal" site sending content that contains script to a 
network server that can log t he content in audit trail (e.g., 
log) files. Given that a browser may have been configured a 
heightened trust for files residing on the server, in various 
embodiments, when a user reviews the audit trail files of 
Web and other e-commerce servers by using the browser, a 
script may be executed on the network client with the trust 
level of the network server that delivered the audit trail 
records (e.g., with a heightened trust level). Execution of 
this script may cause an attack which may occur long after 
the script was sent to the network server. This attack is 
preventable using the same methods and procedures 
described above to prevent cross site scripting, such as the 
"criminal" attacks described above. A filter, such as the one 
described in FIG. 13, running on a network server, such as 
a Web server, or running on a network client, such as a PC 
browser, can filter for script control characters and encode 
the characters, reject the characters or reject the entire 
record. 

[0110] In another exemplary embodiment of the present 
invention, transaction system 100 may be configured with 
one or more biometric scanners, processors and/or systems. 



FIG. 14 illustrates an exemplary transaction system 1400 in 
accordance with the present invention, wherein exemplary 
components for use in completing an electronic transaction 
are depicted. While the invention maybe described with the 
use of a smartcard, a smartcard is not required and the 
invention contemplates similar embodiments using only an 
account code or number. 

[0111] System 1400 may include smartcard 202 having an 
integrated circuit (IC) 1410. Smartcard 202 may also be 
configured with a biometric sensor 1404, described in fur- 
ther detail herein. System 1400 may also comprise smart- 
card reader 204 configured to communicate with smartcard 
202, computer 110, wallet 140, merchant 120 and/or an 
access point 1450. 

[0112] Access point 1450 may be configured as any point 
of interaction between a smartcard user and transaction 
system 1400. For example, access point 1450 may include a 
merchant POS device, a kiosk, a terminal, a computer 
interface, and/or any other device for facilitating user access 
to transaction system 1400. Smartcard reader 204 may be 
configured with a biometric sensor 1604, described in fur- 
ther detail herein. Smartcard 202 may communicate with 
network 102 through smartcard reader 204. 

[0113] A biometric system may include one or more 
technologies, or any portion thereof, to facilitate recognition 
of a personal identifier, such as, for example a biometric. As 
used herein, a personal identifier may include a user's voice, 
fingerprint, facial, ear, signature, vascular patterns, DNA 
sampling, hand geometry, sound, olfactory, keystroke/typ- 
ing, iris, retinal, brainwaves, or any other biometric relating 
to recognition based upon any body part, function, system, 
attribute and/or other characteristic, or any portion thereof. 
As used herein, tile terms ••personal identifier" and "biomet- 
ric" may be used interchangeably. Certain of these technolo- 
gies will be described in greater detail herein. Moreover, 
while some of the examples discussed herein may include a 
particular biometric system or sample, the invention con- 
templates any of the biometrics discussed herein in any of 
the embodiments. 

[0114] The biometric system may be configured as a 
security system and may include a registration procedure in 
which a user of a transaction instrument proffers a sample of 
his fingeqirints, DNA, retinal scan, voice, and/or other 
biometric sample to an authorized sample receiver (ASR). 
As used herein, a transaction instrument may refer to a 
physical smartcard, debit card, charge card, loyalty card, 
radio-frequency enabled card, or the like. Further, a trans- 
action instrument may also refer to the electronic informa- 
tion stored and/or associated with a physical card. As used 
herein, all transaction instruments will be referred to herein 
as "smartcard 202." An ASR may include a local database, 
a remote database, a portable storage device, a host system, 
an issuer system, a merchant system, a smartcard issuer 
system, an employer, a financial institution, a non-financial 
institution, a loyalty point provider, a company, the military, 
the government, a school, a travel entity, a transportation 
authority, a security company, and/or any other system or 
entity that may be authorized to receive and store biometric 
samples and associate the samples with specific biometric 
databases and/or transaction instruments (e.g., smartcards 
202). As used herein, a user of a smartcard, cardmember, or 
any similar phrase may include the person or device holding 
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or in possession of the smartcard, or it may include any 
person or device that accompanies or authorizes the smart- 
card owner to use the smartcard. 

[0115] FIG. 15 illustrates an exemplary registration pro- 
cedure in accordance with the present invention. In one 
embodiment, a cardmember may contact an ASR to submit 
one or more biometric samples to an ASR (step 1501). The 
cardmember may contact the ASR and submit a sample in 
person, through a computer and/or Internet, through soft- 
ware and/or hardware, through a third-party biometric 
authorization entity, through a kiosk and/or biometric reg- 
istration terminal, and/or by any other direct or indirect 
means, communication device or interface for a person to 
contact an ASR. 

[0116] A cardmember may then proffer a biometric sample 
to the ASR (step 1503). As used herein, a biometric sample 
may be any one or more of the biometric samples or 
technologies, or portion thereof, described herein or known 
in the art. By proffering one or more biometric samples, a 
biometric may be scanned by at least one of a retinal scan, 
iris scan, fingerprint scan, hand print scan, hand geometry 
scan, voice print scan, vascular scan, facial and/or ear scan, 
signature scan, keystroke scan, olfactory scan, auditory 
emissions scan, DNA scan, and/or any other type of scan to 
obtain a biometric sample. Upon scanning the sample, the 
system may submit the scanned sample to the ASR in 
portions during the scan, upon completing the scan or in 
batch mode after a certain time period. The scanned sample 
may include a hardcopy (e.g., photograph ). digital represen- 
tation, an analog version or any other configuration for 
transmitting the sample. The ASR receives the sample and 
the ASR may also receive copies of a cardmember's bio- 
metric data along with the sample or at a different time (or 
within a different data packet) from receiving the sample. 

[0117] The ASR and/or cardmember may correlate and/or 
register the sample with cardmember information to create 
a data packet for the sample and store the data packet in 
digital and/or any storage medium known in the art. As used 
herein, a data packet may include the digitized information 
relating to at least one of a biometric sample, a registered 
biometric sample, a stored biometric sample, a proffered 
biometric, a proffered biometric sample, cardmember infor- 
mation, smartcard information and or any other information. 
The terms "data packet,""biomctric sample." and ••sample" 
may be used interchangeably. As used herein, registered 
samples may include samples that have been proffered, 
stored and associated with cardmember information. By 
storing the data packet in digital format, the ASR may 
digitize any information contained in one of the biometric 
scans described herein. By storing the data packet in any 
storage medium, the ASR may print and/or store any bio- 
metric sample. Hardcopy storage may be desirable for 
back-up and archival purposes. 

[0118] The biometric sample may also be associated with 
user information to create a data packet (step 1505). The 
sample may be associated with user information at any step 
in the process such as, for example, prior to submission, 
during submission and/or after submission. In one embodi- 
ment, the user may input a PIN number or zip code into 
access point 1450, then scan the biometric to create the 
biometric sample. The local access point may associate the 
biometric sample data with the PIN and zip code, then 



transmit the entire packet of information to the ASR. In 
another embodiment, the access point may facilitate trans- 
mitting the sample to an ASR, and during the transmission, 
the sample may be transmitted through a third system which 
adds personal information to the sample. 
[0119] The information associated with the biometric 
sample may include any information such as, for example, 
cardmember information, smartcard 202 information, smart- 
card 202 identifier information, smartcard 202 issuer infor- 
mation, smartcard 202 operability information, and/or 
smartcard 202 manufacturing information. Smartcard 202 
information may be not limited to smartcard chip informa- 
tion and may include information related to any transaction 
instrument such as transponders, credit cards, debit cards, 
merchant-specific cards, loyalty point cards, cash accounts 
and any other transaction instruments and/or accounts. The 
cardmember information may also contain information 
about the user including personal information — such as 
name, address, and contact detads; financial information — 
such as one or more financial accounts associated with the 
cardmember; loyalty point information — such as one or 
more loyalty point accounts (e.g., airline miles, charge card 
loyalty points, frequent diner points) associated with the 
cardmember; and or non-linancial information — such as 
employee information, employer information, medical 
information, family information, and/or other information 
that may be used in accordance with a cardmember. 

[0120] for example, a cardmember may have previously 
associated a credit card account (or charge card account), a 
debit card account, and a frequent flier account with his 
biometric sample which may be stored at an ASR. Later, 
when cardmember desires to purchase groceries, cardmem- 
ber may submit his biometric sample while using smartcard 
202 for the purchase at access point 1450. Access point 1450 
may facilitate sending the biometric sample to the ASR such 
that the ASR authorizes the biometric sample and checks a 
look-up table in the ASR database to determine if any 
information may be associated with the sample. If informa- 
tion (e.g., financial accounts) may be associated with the 
sample, the ASR may transmit the information to the access 
point. The access point may then present cardmember with 
a list of the three accounts associated with the biometric 
sample. Cardmember and/or a merchant may then chose one 
of the accounts in order to continue and finalize the trans- 



[0121] In another embodiment, cardmember may associ- 
ate each account with a different biometric sample. For 
example, during registration, cardmember may submit a 
sample of his right index fingerprint, and request that the 
system primarily associate this sample with a particular 
credit card account. Cardmember may additionally submit a 
sample of his left index fingerprint and request that the 
system primarily associate the sample with a particular debit 
account. Additionally, cardmember may submit his right 
thumbprint and request that the system primarily associate 
that sample with a particular frequent flier account. By 
"primarily" associating a sample with an account, the sys- 
tem initially associates the sample with that account. For 
example, cardmember submitting his right index fingerprint 
for a financial transaction may have money for the transac- 
tion taken from his credit card account. Cardmember may 
additionally specify which accounts should be secondarily 
associated with a sample. For example, cardmember may 
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have a debit card account secondarily associated with his 
right index fingerprint. As a result, if cardmember submits 
his right index fingerprint for a transaction, and the primary 
account associated with the sample is overdrawn or unavail- 
able, the secondary account may be accessed in order to 
further the transaction. 

[0122] While primary and secondary account association 
are described herein, any number of accounts may be 
associated with a sample. Moreover, any hierarchy or rules 
may be implemented with respect to the association. For 
example, the cardmember may instruct the system to access 
a debit card account when it receives a right index finger- 
print sample, the purchase qualifies lor loyalty points with a 
certain airline and the purchase amount is less than $50. The 
cardmember may additionally instruct the system to access 
a credit card account if it receives a right index fingerprint 
sample, the purchase does not qualify for airline miles and 
the purchase amount is greater than $50. Further, while 
fingerprint samples are discussed herein, any biometric 
sample may have one or more accounts associated with it 
and may be used to facilitate a transaction using any of the 
routines discussed herein. 

[0123] The ASR and/or cardmember may associate a 
specific smarlcard 202 identifier with the biometric sample 
by any method known in the art for associating an identifier 
(e.g., through the use of software, hardware and/or manual 
entry.) The ASR may additionally verify the cardmember 
and or smarlcard 202 by using one or more forms of the 
user's secondary identification (step 1507). For example, the 
ASR may verify the cardmember by matching the smartcard 
information to information retrieved from scanning infor- 
mation from a cardmember's driver's license. The ASR may 
verify smarlcard 202 by contacting the vendor of smarlcard 
202 to confirm that smartcard 202 was issued to a specific 
cardmember. In another embodiment, the ASR may activate 
smartcard 202 during the registration procedure to confirm 
that the smartcard 202 smartcard chip identifier and other 
information may be properly associated with the cardmem- 
ber and the cardmember's specific biometric samples. The 
ASR may additionally employ one or more verification 
methods to confirm that the biometric sample belongs to the 
user, such as, for example, the ASR may request from the 
user demographic information, further biometric samples 
and/or any other information. As used herein, "confirm, 
""confirmation" or any similar term includes verifying or 
substantially verifying the accuracy, existence, non-exist- 
ence, corroboration, and/or the like of the information, 
component, or any portion thereof. The ASR may addition- 
ally employ one or more additional processing methods in 
order to facilitate association of a biometric sample. As used 
herein, the term processing may include scanning, detecting, 
associating, digitizing, printing, comparing, storing, 
encrypting, decrypting, and/or verifying a biometric and/or 
a biometric sample, or any portion thereof. 

[0124] Upon association, authentication and/or verifica- 
tion of the biometric sample and smartcard 202, the system 
may create a data packet store the data packet and smartcard 
202 identifier (step 1509) in one or more databases on and/or 
in communication with system 1400 via a network, server, 
computer, or any other means of communicating as 
described herein. The database(s) may be any type of 
database described herein. For example, a biometric sample 
stored on smartcard 202 may be stored in the memory and/or 



other database of a transaction instrument. The database(s) 
may be located at or operated by any of the entities discussed 
herein such as, for example, the ASR and/or by a third-party 
biometric database operator. 

[0125] The information stored in the database may be 
sorted or stored according to one or more characteristics 
associated with the sample in order to facilitate faster access 
to the stored sample. For example, fingerprint samples may 
be stored in a separate database than voice prints. As another 
example, all fingerprints with certain whirl patterns may be 
stored in a separate sub-database and/or database from 
fingerprints with arch patterns. 

[0126] The biometric samples may also be stored and/or 
associated with a personal identification number (PIN) and/ 
or other identifier to facilitate access to the sample. The PIN 
may be cardmember selected or randomly assigned to the 
biometric sample. The PIN may consist of any characters 
such as, for example, alphanumeric characters and/or for- 
eign language characters. 

[0127] The system may further protect the samples by 
providing additional security with the sample. The security 
may include, for example, encryption, decryption, security 
keys, digital certificates, firewalls and/or any other security 
methods known in the art and discussed herein. One or more 
security vendors may utilize the security methods to store 
and/or access the biometric samples. The present invention 
anticipates that storage of the biometric samples may be 
such that a sample may be first encrypted and/or stored 
under a security procedure, such that the sample may only 
be accessed by a vendor with the proper level of access or 
security which corresponds to or provides access to the 
stored sample. The samples may be accessible by certain 
vendors such as, for example, smartcard 202 transaction 
account provider system, an issuer system, a merchant 
system, a smartcard issuer system, an employer, a financial 
institution, a non-financial institution, a loyalty-point pro- 
vider, a company, the military, the government, a school, a 
travel entity, a transportation authority, and/or a security 
company. 

[0128] The smartcard of the invention may include a 
particular security system wherein the security system incor- 
porates a particular biometric system. As shown in FIG. 14, 
smartcard 202 may include a biometric security system 1402 
configured for facilitating biometric security using, for 
example, fingerprint samples. As used herein, fingerprint 
samples may include samples of one or more fingerprints, 
thumbprints, palmprints, footprints, and/or any portion 
thereof. Biometric security system 1402 may include a 
biometric sensor 1404 which may be configured with a 
sensor and/or other hardware and/or software for acquiring 
and/or processing the biometric data from the person such 
as, for example, optical scanning, capacitance scanning, or 
otherwise sensing the portion of cardmember. In one 
embodiment, biometric sensor 1404 of the security system 
1402 may scan a finger of a cardmember in order to acquire 
his fingerprint characteristics into smartcard 202. Biometric 
sensor 1404 may be in communication with integrated 
circuit 110 such that IC 110 receives the fingerprint infor- 
mation and transmits a signal to smartcard 202 to facilitate 
activating the operation of smartcard 202. A power source 
may be in communication with biometric sensor 1404 and 
IC 110 to provide the desired power for operation of the 
biometric security system components. 
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[0129] In one exemplary application of smartcard 202 
incorporating biometric security system 1402, the user may 
place his finger on the biometric sensor to initiate the mutual 
authentication process between smartcard 202 and smart- 
card reader 204, and/or to provide verification of the user's 
identity. Smartcard 202 may digitize the fingerprint and 
compare it against a digitized fingerprint stored in a database 
included on smartcard 202. The fingerprint information may 
additionally be compared with information from one or 
more third-party databases communicating with smartcard 
202 through any communication software and/or hardware, 
including for example, smartcard reader 204, a Universal 
Serial Bus (USB) connection, a wireless connection, a 
computer, a network and/or any other means for communi- 
cating. This transfer of information may include use of 
encryption, decryption, security keys, digital certificates 
and/or other security devices to confirm the security of the 
sample. Smartcard 202 may additionally communicate with 
third-party databases to facilitate a comparison between 
smartcard 202 identifier and other smartcard identifiers 
stored with the biometric samples. As used herein, compare, 
comparison and similar terms may include determining 
similarities, differences, existence of elements, non-exist- 
ence of elements and/or the like. 

[0130] A CPU such as, for example, customer computer 
110, and/or merchant 130 may be configured to facilitate the 
local comparison to authenticate the biometric and validate 
the information. Any of the embodiments may alternatively 
or additionally include remote comparisons performed or 
controlled by one or more third-party security vendors. One 
or more comparison techniques and/or technologies may be 
used for comparisons. For example, for fingerprint compari- 
sons, the CPU may utilize an existing database to compare 
fingerprint minutia such as, for example, ridge endings, 
bifurcation, lakes or enclosures, short ridges, dots, spurs and 
crossovers, pore size and location, Henry System categories 
such as loops, whorls, and arches, and/or any other method 
known in the art for fingerprint comparisons. 

[0131] Smartcard 202 may additionally be configured with 
secondary security procedures to confirm that fake biometric 
samples may be not being used. For example, to detect the 
use of fake fingers, smartcard 202 may be further configured 
to measure blood How, to check for correctly aligned ridges 
at the edges of the fingers, and/or any other secondary 
procedure to reduce biometric security fraud. Other security 
procedures for ensuring the authenticity of biometric 
samples may include monitoring pupil dilation for retinal 
and/or iris scans, pressure sensors, blinking sensors, human 
motion sensors, body heat sensors, eyeball pressure sensors 
and/or any other procedures known in the art for authenti- 
cating the authenticity of biometric samples. 

[0132] After verifying the biometric information, smart- 
card 202 and smartcard reader 204 may begin authentica- 
tion, and the transaction may proceed accordingly. However, 
the invention contemplates that the verification of biometric 
information may occur at any point in the transaction such 
as, for example, after the mutual authentication. At any point 
in the transaction, the system may additionally request 
cardmember to enter a PIN and/or other identifier associated 
with the transaction account and/or biometric sample to 
provide further verification of cardmember's identification. 
As part of the transaction, cardmember payor may be 
requested to select from one of the financial accounts, 



loyalty accounts, credit accounts, debit account, and/or other 
accounts associated with the biometric sample. The user 
may be presented with a list of account options on a display 
associated with smartcard reader 204, smartcard 202, a 
third-party security device and/or any other financial or 
transaction device association with a transaction. In another 
embodiment, a payee may select one of the accounts. For 
example, a department store payee may manually and/or 
automatically select a department store issued account, if 
available, for a transaction. 

[0133] In another exemplary embodiment, biometric secu- 
rity system 1402 may be configured for facilitating biomet- 
ric security using facial recognition or recognition of any 
oilier body part or object. As discussed herein, facial rec- 
ognition may include recognition of any facial features 
obtained through a facial scan such as, for example, the eyes, 
nose, cheeks, jaw line, forehead, chin, ear features, head 
shape, hairline, neck features, shoulder height, forehead 
slope, lip shape, distance between the ears and/or any 
portion thereof. Biometric security system 1402 may include 
a biometric sensor 1404 which may be configured with a 
video camera, optical scanner, imaging radar, ultraviolet 
imaging and/or other hardware and/or software for acqu iring 
the biometric data from the person such as, for example 
video scanning, optical scanning or otherwise sensing any 
portion of cardmember. In one embodiment, biometric sen- 
sor 1404 of the security sy stem 1402 may scan the face of 
a cardmember in order to acquire his facial characteristics 
into smartcard 202. Biometric sensor 1404 may be in 
communication with IC 110 such that sensor 1404 receives 
the facial information and transmits a signal to the CPU to 
facilitate activating the operation of smartcard 202. A power 
source may be in communication with biometric sensor 
1404 and IC 110 to provide the desired power for operation 
of the biometric security system components. 
[0134] In one exemplary application of smartcard 202 
incorporating biometric security system 1402, system 1402 
may scan the facial features of the cardmember to initiate the 
mutual authentication process between smartcard 202 and 
smartcard reader 204, and/or to provide verification of the 
user's identity. Security system 1402 may be configured 
such that cardmember may stand at least two-feet away from 
sensor 1404. Additionally, sensor 1404 may be configured to 
detect facial features of a user turned at least 30 degrees 
toward the camera. 

[0135] Smartcard 202 may digitize the facial scan and 
compare it against a digitized facial scan stored in a database 
included on smartcard 202. The facial scan information may 
additionally be compared with information from one or 
more third-party databases communicating with smartcard 
202 through any communication software and/or hardware, 
including for example, smartcard reader 204, a USB con- 
nection, a wireless connection, a computer, a network and/or 
any other means for communicating. This transfer of infor- 
mation may include use of encryption, decryption, security 
keys, digital certificates and/or other security devices to 
confirm the security of the sample. Smartcard 202 may 
additionally communicate with third-party databases to 
facilitate a comparison between smartcard 202 identifier and 
other smartcard identifiers stored with the biometric 
samples. 

[0136] The CPU may facilitate the local comparison to 
authenticate the biometric and may validate the information. 
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Any of the embodiments may alternatively or additionally 
include remote comparisons performed or controlled by one 
or more third-party security vendors. One or more compari- 
son techniques and/or technologies may be used for com- 
parisons. For example, for facial recognition, the CPU may 
utilize an existing database to compare nodal points such as 
the distance between the eyes, the width of the nose, the jaw 
line, and the depth of the user's eye sockets. While only 
some types of nodal points are listed, the present invention 
recognizes that it is known that there are over 80 different 
nodal points on a human face that may be used for com- 
parison in the present invention. Additionally, third-party 
devices such as facial recognition software and or hardware 
systems may be used to facilitate facial recognition, such as 
the systems developed by Viisage, Imagis, and Identix 
which employ complex algorithms that facilitate both 
searching facial and/or ear scans and adjusting stored data 
based on eyewear, facial hair, and other changes in outward 
facial and/or ear appearance. 

[0137] Smartcard 202 may additionally be configured with 
secondary security procedures to confirm that fake biometric 
samples may be not being used. For example, to detect the 
use of fake facial features, smartcard 202 may be further 
configured to measure blood flow, to detect a thermal pattern 
associated with facial features, and/or any other secondary 
procedure to reduce biometric security fraud. Other security 
procedures for ensuring the authenticity of biometric 
samples may include monitoring pupil dilation for retina! 
and/or iris scans, pressure sensors, blinking sensors, human 
motion sensors, body heat sensors and/or any other proce- 
dures known in the art for authenticating the authenticity of 
biometric samples. After verifying the biometric informa- 
tion, smartcard 202 and smartcard reader 204 may begin 
authentication by any of the methods described herein. 

[0138] In another exemplary embodiment, biometric secu- 
rity system 1402 may be configured for facilitating biomet- 
ric security using voice recognition. As discussed herein, 
voice recognition may include recognition of voice and/or 
speaker features such as, phonated excitation, whispered 
excitation, frication excitation, compression, vibration, para- 
metric waveforms, tone, pitch, dialect, annunciation, and or 
any portion thereof. As discussed herein, these voice recog- 
nition features may be collectively referred to as a "voice 
print." Biometric security system 1402 may include a bio- 
metric sensor 1404 which may be configured with an audio 
capture device such as a microphone, telephone, cellular 
phone, computer, speaker and/or other hardware and/or 
software for acquiring the biometric data from the person 
such as, for example auditory scanning, recording or other- 
wise sensing the portion of cardmember. 

[0139] In one exemplary application of smartcard 202 
incorporating biometric security system 1402, system 1402 
may capture the voice print of the cardmember to initiate the 
mutual authentication process between smartcard 202 and 
smartcard reader 204, and/or to provide verification of the 
user's identity. In one embodiment, biometric sensor 1404 of 
the security system 1402 may capture a voice print, when a 
user recites, for example, a pass phrase or audible PIN. 
Biometric sensor 1404 may be in communication with IC 
110 such that sensor 1404 receives the voice print and 
transmits a signal to the CPU to facilitate activating the 
operation of smartcard 202. A power source may be in 



communication with biometric sensor 1404 and IC 110 to 
provide the desired power for operation of the biometric 
security system components. 

[0140] Smartcard 202 may digitize the voice print and 
compare it against a digitized voice print stored in a database 
included on smartcard 202. The voice print information may 
additionally be compared with information from one or 
more third-party databases communicating with smartcard 
202 through any communication software and/or hardware, 
including for example, smartcard reader 204, a USB con- 
nection, a wireless connection, a computer, a network and/or 
any other means for communicating. The CPU may facilitate 
the local comparison to authenticate the biometric and 
validate the information. Any of the embodiments may 
alternatively or additionally include remote comparisons 
performed or controlled by one or more third-party security 
vendors. 

[0141] One or more comparison techniques and/or tech- 
nologies may be used for comparisons. For example, for 
voice recognition, the CPU may utilize an existing database 
to compare the voice print by comparing voice print wave- 
forms in the time domain, by comparing energy content in 
the voice prints across the frequency domain, by the use of 
stochastic models and/or template models, and/or by any 
other voice recognition method known in the art. This 
transfer of information may include use of encryption, 
decryption, security keys, digital certificates and/or other 
security devices to confirm the security of the sample. 
Smartcard 202 may additionally communicate with third- 
party databases to facilitate a comparison between smartcard 
202 identifier and other smartcard identifiers stored with the 
biometric samples. Further, the present invention anticipates 
use of one or more third-party devices such as voice recog- 
nition software and/or hardware systems to facilitate voice 
print comparisons, such as, for example SAFLINK and 
Voice Security Systems. 

[0142] Smartcard 202 and/or any other third-party security 
vendor system used in connection with smartcard 202 may 
additionally be configured with secondary security proce- 
dures to confirm that fake biometric samples are not being 
used. For example, to detect the use of a recorded voice, 
system 1402 may be further configured to detect audio noise 
associated with an electronic device and/or any other sec- 
ondary procedure to thwart biometric security fraud. After 
verifying the biometric information, smartcard 202 and 
smartcard reader 204 may begin authentication by the meth- 
ods described herein. 

[0143] In another exemplary embodiment of the present 
invention, biometric security system 1402 may be config- 
ured for facilitating biometric security using signature rec- 
ognition. As discussed herein, signature recognition may 
include recognition of the shape, speed, stroke, stylus pres- 
sure, timing information, character height and width and/or 
other signature information and/or any portion thereof dur- 
ing the act of signing. As discussed herein, these signature 
recognition features may be collectively referred to as a 
"signature scan." Biometric security system 1402 may 
include a biometric sensor 1404 which may be configured 
with an LCD screen, digitizing tablet and/or other hardware 
and or software that facilitates digitization of biometric data 
from the person such as, for example signature scanning, 
recording or otherwise sensing the signature of cardmember. 
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[0144] In one exemplary application of smartcard 202 
incorporating biometric security system 1402, system 1402 
may capture the signature scan of the cardmember to initiate 
the mutual authentication process between smartcard 202 
and smartcard reader 204, and/or to provide verification of 
the user's identity. In one embodiment, biometric sensor 
1404 of the security system 1402 may capture a signature 
scan, when a user signs, for example, his name or a specified 
word or phrase. Biometric sensor 1404 may be in commu- 
nication with IC 110 such that sensor 1404 receives the 
signature scan and transmits a signal to the CPU to facilitate 
activating the operation of smartcard 202. A power source 
may be in communication with biometric sensor 1404 and 
IC 110 to provide the desired power for operation of the 
biometric security system components. 

[0145] Smartcard 202 may digitize the signature scan and 
compare it against a digitized signature scan stored in a 
database included on smartcard 202. The signature scan 
information may additionally be compared with information 
from one or more third-party databases communicating with 
smartcard 202 through any communication software and/or 
hardware, including for example, smartcard reader 204, a 
USB connection, a wireless connection, a computer, a 
network and/or any other means for communicating. The 
CPU may facilitate the local comparison to authenticate the 
biometric and validate the information. Any of the embodi- 
ments may alternatively or additionally include remote 
comparisons performed or controlled by one or more third- 
party security vendors. 

[0146] For example, for voice recognition, the CPU may 
utilize an existing database to compare the features of a 
signature scan by comparing graphs, charts, and or other 
data relating to shape, speed, stroke, stylus pressure, timing 
information, character height and width and/or by any other 
signature recognition data. This transfer of information may 
include use of encryption, decryption, security keys, digital 
certificates and/or other security devices to confirm the 
security of the sample. Smartcard 202 may additionally 
communicate with Ihird-parly databases to facilitate a com- 
parison between smartcard 202 identifier and other smart- 
card identifiers stored with the biometric samples. Further, 
the present invention anticipates use of one or more third- 
party devices such as signature recognition software and/or 
hardware systems lo facilitate signature scan comparisons, 
such as, for example CyberSIGN, LCI Computer Group, and 
Xenetek. 

[0147] Smartcard 202 and/or any other third-party security 
vendor system used in connection with smartcard 202 may 
additionally be configured with secondary security proce- 
dures to confirm that fake biometric samples are not being 
used. For example, to detect the use of a false signature 
device, system 1402 may be further configured to detect a 
thermal pattern associated with a human hand and/or any 
other secondary procedure to thwart biometric security 
fraud. After verifying the biometric information, smartcard 
202 and smartcard reader 204 may begin authentication by 
the methods described herein. 

[0148] In another exemplary embodiment, biometric secu- 
rity system 1402 may be configured for facilitating biomet- 
ric security using vascular pattern recognition. As discussed 
herein, vascular pattern may include recognition of struc- 
tures, depths, and other biometric reference points of arterial 



tissues, vein tissues, capillary tissues, epithelial tissues, 
connective tissues, muscle tissues, nervous and/or other 
inner tissues and/or any portion thereof. As discussed herein, 
these vascular pattern features may be collectively referred 
to as a "vascular scan." Biometric security system 1402 may 
include a biometric sensor 1404 which may be configured 
with an optical scanner, x-ray, ultrasound, computed tomog- 
raphy, thermal scanner and/or other hardware and/or soft- 
ware that facilitates capture of biometric data from the 
person such as, for example scanning, detecting or otherwise 
sensing a vascular pattern of cardmember. 

[0149] In one exemplary application of smartcard 202 
incorporating biometric security system 1402, system 1402 
may capture the vascular scan of the cardmember to initiate 
the mutual authentication process between smartcard 202 
and smartcard reader 204, and/or to provide verification of 
the user's identity. In one embodiment, biometric sensor 
1404 of the security system 1402 may capture a vascular 
scan, when a user places his hand in front of an optical 
scanner. Biometric sensor 1404 may be in communication 
with IC 110 such that sensor 1404 receives the vascular scan 
and transmits a signal to the CPU to facilitate activ ating the 
operation of smartcard 202. A power source may be in 
communication with biometric sensor 1404 and IC 110 to 
provide the desired power for operation of the biometric 
security system components. 

[0150] Smartcard 202 may digitize the vascular scan based 
on biometric reference points and compare it against a 
digitized vascular scan stored in a database included on 
smartcard 202. The vascular scan information may addition- 
ally be compared with information from one or more third- 
party databases communicating with smartcard 202 through 
any communication software and/or hardware, including for 
example, smartcard reader 204, a USB connection, a wire- 
less connection, a computer, a network and/or any other 
means for communicating. The CPU may facilitate the local 
comparison to authenticate the biometric and validate the 
information. Any of the embodiments may alternatively or 
additionally include remote comparisons performed or con- 
trolled by one or more third-party security vendors. 

[0151] For example, for vascular pattern recognition, the 
CPU may utilize an existing database to compare the vas- 
cular scan by comparing biometric reference points, vascu- 
lar coordinates, vascular and/or tissue lengths, widths and 
depths; blood pressure including waveforms, dicrotic 
notches, diastolic pressure, systolic pressure, anacrotic 
notches and pulse pressure, and/or any other characteristic of 
vascular and/or tissue patterns. This transfer of information 
may include use of encryption, decryption, security keys, 
digital certificates and/or other security devices to confirm 
the security of the sample. Smartcard 202 may additionally 
communicate with third-party databases to facilitate a com- 
parison between smartcard 202 identifier and other smart- 
card identifiers stored with the biometric samples. Further, 
the present invention anticipates use of one or more third- 
party devices such as vascular pattern recognition software 
and/or hardware systems to facilitate vascular scan compari- 
sons, such as, for example VEID International, Identica and 
ABT Advanced Biometric Technologies. 

[0152] Smartcard 202 and/or any other third-party security 
vendor system used in connection with smartcard 202 may 
additionally be configured with secondary security proce- 
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dures to confirm that fake biometric samples are not being 
used. For example, to detect the use of a false vascular 
pattern, system 1402 may be further configured to detect a 
thermal pattern associated will] vascular patterns and or an\ 
other secondary procedure to thwart biometric security 
fraud. After verifying the biometric information, smartcard 
202 and smartcard reader 204 may begin authentication by 
the methods described herein. 

[0153] In another exemplary embodiment, biometric secu- 
rity system 1402 may be configured for facilitating biomet- 
ric security using DNA biometrics. As discussed herein, 
DNA biometrics may include recognition of structures, gene 
sequences, and other genetic characteristics of skin tissue, 
hair tissue, and/or any other human tissue and/or any portion 
thereof containing genetic information. As discussed herein, 
these genetic features may be collectively referred to as a 
"DNA scan." Biometric security system 1402 may include a 
biometric sensor 1404 which may be configured with an 
infrared optical sensor, a chemical sensor and/or other 
hardware and/or software that facilitates capture of biomet- 
ric data from the person such as, for example scanning, 
detecting or otherwise sensing a DNA scan of cardmember. 

[0154] In one exemplary application of smartcard 202 
incorporating biometric security system 1402, system 1402 
may capture the DNA scan of the cardmember to initiate the 
mutual authentication process between smartcard 202 and 
smartcard reader 204, and/or to provide verification of the 
user's identity. In one embodiment, biometric sensor 1404 of 
the security system 1402 may capture a DNA scan, when a 
user submits genetic material to sensor 1404. Biometric 
sensor 1404 may be in communication with IC 110 such that 
sensor 1404 receives the DNA scan and transmits a signal to 
the CPU to facilitate activating the operation of smartcard 
202. A power source may be in communication with bio- 
metric sensor 1404 and IC 110 to provide the desired power 
for operation of the biometric security system components. 

[0155] Smartcard 202 may digitize the DNA scan based on 
genetic information reference points and compare it against 
a digitized DNA scan stored in a database included on 
smartcard 202. The DNA scan information may additionally 
be compared with information from one or more third-party 
databases communicating with smartcard 202 through any 
communication software and/or hardware, including for 
example, smartcard reader 204, a USB connection, a wire- 
less connection, a computer, a network and/or any other 
means for communicating. The CPU may facilitate the local 
comparison to authenticate the biometric and validate the 
information. Any of the embodiments may alternatively or 
additionally include remote comparisons performed or con- 
trolled by one or more third-party security vendors. 

[0156] For example, for DNA recognition, the CPU may 
utilize an existing database to compare the DNA scan by 
comparing nucleotides, code sequences, regulatory regions, 
initiation and stop codons, exon/intron borders, and/or any 
other characteristics of DNA. This transfer of information 
may include use of encryption, decryption, security keys, 
digital certificates and/or other security devices to confirm 
the security of the sample. Smartcard 202 may additionally 
communicate with third-party databases to facilitate a com- 
parison between smartcard 202 identifier and other smart- 
card identifiers stored with the biometric samples. Further, 
the present invention anticipates use of one or more third- 



party devices such as DNA recognition software and/or 

as, for example Applied DNA Sciences. 
[0157] Smartcard 202 and/or any other third-party security 
vendor system used in connection with smartcard 202 may 
additionally be configured with secondary security proce- 
dures to confirm that fake biometric samples are not being 
used. For example, to detect the use false DNA, system 1402 
may be further configured to lake a DNAsample directly off 
a user and/or any other secondary procedure to thwart 
biometric security fraud. After verifying the biometric infor- 
mation, smartcard 202 and smartcard reader 204 may begin 
authentication by the methods described herein. 

[0158] In another exemplary embodiment, biometric secu- 
rity system 1402 may be configured for facilitating biomet- 
ric security using hand geometry biometrics. As discussed 
herein, hand geometry biometrics may include recognition 
of hand geometry parameters, such as, for example, hand 
shape, finger length, finger thickness, finger curvature and/or 
any portion thereof. As discussed herein, these hand geom- 
etry features may be collectively referred to as a "hand 
geometry scan." Biometric security system 1402 may 
include a biometric sensor 1404 which may be configured 
with an infrared optical sensor, a three-dimensional imaging 
system and/or other hardware and/or software that facilitates 
capture of biometric data from the person such as, for 
example scanning, detecting or otherwise sensing a hand 
geometry scan of cardmember. 

[0159] In one exemplary application of smartcard 202 

incorporating biometric security system 1402, system 1402 
may capture the hand geometry scan of the cardmember to 
initiate the mutual authentication process between smartcard 
202 and smartcard reader 204, and/or to provide verification 
of the user's identity. In one embodiment, biometric sensor 
1404 of the security system 1402 may capture a hand 
geometry scan, when a user places his hand in front of an 
optical scanner. Biometric sensor 1404 may be in commu- 
nication with IC 110 such that sensor 1404 receives the hand 
geometry scan and transmits a signal to the CPU to facilitate 
activating the operation of smartcard 202. A power source 
may be in communication with biometric sensor 1404 and 
IC 110 to provide the desired power for operation of the 
biometric security system components. 

[0160] Smartcard 202 may digitize the hand geometry 
scan based on hand geometry parameters and compare it 
against a digitized hand geometry scan stored in a database 
included on smartcard 202. The hand geometry scan infor- 
mation may additionally be compared with information from 
one or more third-party databases communicating with 
smartcard 202 through any communication software and/or 
hardware, including for example, smartcard reader 204, a 
USB connection, a wireless connection, a computer, a 
network and/or any other means for communicating. The 
CPU may facilitate the local comparison to authenticate the 
biometric and validate the information. Any of the embodi- 
ments may alternatively or additionally include remote 
comparisons performed or controlled by one or more third- 
party security vendors. 

[0161] For example, for hand geometry recognition, the 
CPU may utilize an existing database to compare hand 
shape, finger length, finger thickness, finger curvature and/or 
any other of the 90 different hand geometry parameters 
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known in the art. This transfer of information may include 
use of encryption, decryption, security keys, digital certifi- 
cates and/or other security devices to confirm the security of 
the sample. Smartcard 202 may additionally communicate 
with third-party databases to facilitate a comparison between 
smartcard 202 identifier and other smartcard identifiers 
stored with the biometric samples. Further, the present 
invention anticipates use of one or more third-party devices 
such as hand geometry recognition software and/or hard- 
ware systems to facilitate hand geometry scan comparisons, 
such as, for example IR Recognition Services and Human 
Recognition Services. 

[0162] Smartcard 202 and/or any other third-parly security 
vendor system used in connection with smartcard 202 may 
additionally be configured with secondary security proce- 
dures to confirm that fake biometric samples are not being 
used. For example, to detect the use of false hands, system 
1402 may be further configured to measure blood flow, to 
detect body heat and/or any other secondary procedure to 
thwart biometric security fraud. After verifying the biomet- 
ric information, smartcard 202 and smartcard reader 204 
may begin authentication by the methods described herein. 

[0163] In another exemplary embodiment, biometric secu- 
rity system 1402 may be configured for facilitating biomet- 
ric security using auditory emissions biometrics. As dis- 
cussed herein, auditory emissions biometrics may include 
emissions that an ear generates when stimulated by sound, 
such as vibrations and reverberated sound waves and/or any 
portion thereof. As discussed herein, these auditory emis- 
sions features may be collectively referred to as an "auditory 
emissions scan." Biometric security system 1402 may 
include a biometric sensor 1404 which may be configured 
with an infrared optical sensor, an auditory sensor, an 
auditory generator and/or other hardware and/or software 
that facilitates the capture of biometric data from the person 
such as, for example sound generating, scanning, detecting 
or otherwise sensing an auditory emissions scan of card 
member. 

[0164] In one exemplary application of smartcard 202 
incorporating biometric security system 1402, system 1402 
may capture the auditory emissions scan of the cardmember 
to initiate the mutual authentication process between smart- 
card 202 and smartcard reader 204, and/or to provide 
verification of the user's identity. In one embodiment, bio- 
metric sensor 1404 of the security system 1402 may capture 
an auditory emissions scan, when a user hears an auditory 
stimulant and the user's auditory emissions may be detected 
by biometric sensor 1404. Biometric sensor 1404 may be in 
communication with IC 110 such that sensor 1404 receives 
the auditory emissions scan and transmits a signal to the 
CPU to facilitate activating the operation of smartcard 202. 
A power source may be in communication with biometric 
sensor 1404 and IC 110 to provide the desired power for 
operation of the biometric security system components. 

[0165] Smartcard 202 may digitize the auditory emissions 
scan based on emissions waveforms and compare it against 
a digitized auditory emissions scan stored in a database 
included on smartcard 202. The auditory emissions scan 
information may additionally be compared with information 
from one or more third-party databases communicating with 
smartcard 202 through any communication software and/or 
hardware, including for example, smartcard reader 204, a 



USB connection, a wireless connection, a computer, a 
network and/or any other means for communicating. The 
CPU may facilitate the local comparison to authenticate the 
biometric and validate the information. Any of the embodi- 
ments may alternatively or additionally include remote 
comparisons performed or controlled by one or more third- 
party security vendors. 

[0166] For example, for auditory emissions recognition, 
the CPU may utilize an existing database to compare emis- 
sions difference in frequency, wavelength, and/or other 
characteristics between the transmitted and reverberated 
sound waves. This transfer of information may include use 
of encryption, decryplion, security keys, digital certificates 
and/or other security devices to confirm the security of the 
sample. Smartcard 202 may additionally communicate with 
third-party databases to facilitate a comparison between 
smartcard 202 identifier and other smartcard identifiers 
stored with the biometric samples. Further, the present 
invention anticipates use of one or more third-party devices 
such as auditory emissions recognition software and/or 
hardware systems to facilitate auditory emissions scan com- 
parisons, such as, for example those developed by the 
University of Southampton. 

[0167J Smartcard 2(12 and or any oilier third-parly security 
vendor system used in connection with smartcard 202 may 
additionally be configured with secondary security proce- 
dures in confirm that lake biometric samples are not being 
used. For example, to detect the use of false auditory 
emissions scans, system 1402 may be further configured to 
detect electronic noise associated with a device producing 
electronic auditory emissions and/or any other secondary 
procedure to thwart biometric security fraud. After verifying 
the biometric information, smartcard 202 and smartcard 
reader 204 may begin authentication by the methods 
described herein. 

[0168] In another exemplary embodiment, biometric secu- 
rity system 1402 may be configured for facilitating biomet- 
ric security using olfactory biometrics. As discussed herein, 
olfactory biometrics may include odorants that a body 
generates when odor evaporates from and/or any portion 
thereof. As discussed herein, these odorants may be collec- 
tively referred to as a "smellprint." Biometric security 
system 1402 may include a biometric sensor 1404 which 
may be configured with an electronic sensor, a chemical 
sensor, and/or an electronic or chemical sensor configured as 
an array of chemical sensors, wherein each chemical sensor 
may detect a specific odorants, or smell. In another embodi- 
ment, biometric sensor 1404 may be configured as a gas 
chromatograph, spectrometer, conductivity sensor, piezo- 
electric sensor and/or other hardware and/or software that 
facilitates the capture of biometric data from the person such 
as, for example, scanning, detecting or otherwise sensing a 
smellprint of cardmember. 

[0169] In one exemplary application of smartcard 202 
incorporating biometric security system 1402, system 1402 
may capture the smellprint of the cardmember to initiate the 
mutual authentication process between smartcard 202 and 
smartcard reader 204, and/or to provide verification of the 
user's identity. In one embodiment, biometric sensor 1404 of 
the security system 1402 may capture a smellprint, when a 
user stands within at least two feet of sensor 1404. Biometric 
sensor 1404 may be in communication with IC 110 such that 
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sensor 1404 receives the smellprint and transmits a signal to 
the CPU to facilitate activating the operation of smartcard 
202. A power source may be in communication with bio- 
metric sensor 1404 and IC 110 to provide the desired power 
for operation of the biometric security system components. 

[0170] Smartcard 202 may digitize the smellprint and 
compare it against a digitized smellprint stored in a database 
included on smartcard 202. The smellprint information may 
additionally be compared with information from one or 
more third-party databases communicating with smartcard 
202 through any communication software and/or hardware, 
including for example, smartcard reader 204, a USB con- 
nection, a wireless connection, a computer, a network and/or 
any other means for communicating. The CPU may facilitate 
the local comparison to authenticate the biometric and 
validate the information. Any of the embodiments may 
alternatively or additionally include remote comparisons 
performed or controlled by one or more third-party security 
vendors. 

[0171] For example, for smellprints, the CPU may utilize 
an existing database to compare the difference in molecular 
structures, chemical compounds, temperature, mass differ- 
ences, pressure, force, and odorants by using statistical, 
ANN and neuromorphic techniques. This transfer of infor- 
mation may include use of encryption, decryption, security 
keys, digital certificates and/or other security devices to 
confirm the security of the sample. Smartcard 202 may 
additionally communicate with lhird-parl> databases to 
facilitate a comparison between smartcard 2(12 identifier and 
other smartcard identifiers stored with the biometric 
samples. Further, the present invention anticipates use of one 
or more third-party devices such as smellprint recognition 
software and/or hardware systems to facilitate smellprint 
comparisons, such as, for example those developed by 
Company Mastiff Electronic Systems. 

[0172] Smartcard 202 and/or any other third-party security 
vendor system used in connection with smartcard 202 may 
additionally be configured with secondary security proce- 
dures to confirm that fake biometric samples are not being 
used. For example, to delect the use of a false odorant, 
system 1402 may be further configured to detect man-made 
smells, abnormal odorants, body heat and/or any other 
secondary procedure to thwart biometric security fraud. 
After verifying the biometric information, smartcard 202 
and smartcard reader 204 may begin authentication by the 
methods described herein. 

[0173] In another exemplary embodiment, biometric secu- 
rity system 1402 may be configured for facilitating biomet- 
ric security using keystroke/typing recognition biometrics. 
As discussed herein, keystroke/typing recognition biomet- 
rics may include recognition of the duration of keystrokes, 
latencies between keystrokes, inter-keystroke times, typing 
error frequency, force keystrokes and/or any portion thereof. 
As discussed herein, these features may be collectively 
referred to as a "keystroke scan." Biometric security system 
1402 may include a biometric sensor 1404 which may be 
configured with an electronic sensor, an optical sensor, a 
keyboard, and/or other hardware and/or software that facili- 
tates the capture of biometric data from the person such as, 
for example, scanning, detecting or otherwise sensing a 
keystroke scan of cardmember. A keyboard may include any 



type of input device, such as, for example, flat electronic 
pads with labels as keys, touch screens, and/or any other 
types of input devices. 

[0174] In one exemplary application of smartcard 202 
incorporating biometric security system 1402, system 1402 
may capture the keystroke scan of the cardmember to initiate 
the mutual authentication process between smartcard 202 
and smartcard reader 204, and/or to provide verification of 
the user's identity. In one embodiment, biometric sensor 
1404 of the security system 1402 may capture a keystroke 
scan, when a user types, for example, a PIN or pass phrase 
into a keyboard configured with sensor 1404. Biometric 
sensor 1404 may be in communication with IC 110 such that 
sensor 1404 receives the keystroke scan and transmits a 
signal to the CPU to facilitate activating the operation of 
smartcard 202. A power source may be in communication 
with biometric sensor 1404 and IC 110 to provide the desired 
power for operation of the biometric security system com- 
ponents. 

[0175] Smartcard 202 may digitize the keystroke scan 
based on keystroke characteristics and compare the scan 
against a digitized keystroke scan stored in a database 
included on smartcard 202. The keystroke scan information 
may additionally be compared with information from one or 
more third-party databases communicating with smartcard 
202 through any communication software and/or hardware, 
including for example, smartcard reader 204, a USB con- 
nection, a wireless connection, a computer, a network and/or 
any other means for communicating. The CPU may facilitate 
the local comparison to authenticate the biometric and 
validate the information. Any of the embodiments may 
alternatively or additionally include remote comparisons 
performed or controlled by one or more third-party security 
vendors. 

[0176] For example, for keystroke scans, the CPU may 
utilize an existing database to compare the behavioral, 
temporal and physical characteristics associated with key- 
strokes. This transfer of information may include use of 
encryption, decryption, security keys, digital certificates 
and/or other security devices to confirm the security of the 
sample. Smartcard 202 may additionally communicate with 
third-party databases to facilitate a comparison between 
smartcard 202 identifier and other smartcard identifiers 
stored with the biometric samples. Further, the present 
invention anticipates use of one or more third-party devices 
such as keystroke scan recognition software and/or hardware 
systems to facilitate keystroke scan comparisons, such as, 
for example those developed by BioPassword® by BioNet 
Systems, LLC. 

[0177] Smartcard 202 and/or any other third-party security 
vendor system used in connection with smartcard 202 may 
additionally be configured with secondary security proce- 
dures to confirm that fake biometric samples are not being 
used. For example, to detect the use of a false keystroke, 
system 1402 may be further configured to detect body heat 
and/or any other secondary procedure to thwart biometric 
security fraud. After verifying the biometric information, 
smartcard 202 and smartcard reader 204 may begin authen- 
tication by the methods described herein. 

[0178] In another exemplary embodiment, biometric secu- 
rity system 1402 may be configured for facilitating biomet- 
ric security using iris scan biometrics. As discussed herein, 
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iris scan biometrics may include recognition of characteris- 
tics of the colored tissues surrounding the pupil, such as the 
rings, furrows and freckles and/or any portion thereof. As 
discussed herein, these characteristics may be collectively 
referred to as an "iris scan." Biometric security system 1402 
may include a biometric sensor 1404 which may be config- 
ured with a video camera, an optical scanner, a digital 
camera, a charge coupled device and/or other hardware 
and/or software that facilitates the capture of biometric data 
from the person such as, for example, scanning, detecting or 
otherwise sensing an iris scan of cardmember. 

[0179] In one exemplary application of smartcard 202 
incorporating biometric security system 1402, system 1402 
may capture the iris scan of the cardmember to initiate the 
mutual authentication process between smartcard 202 and 
smartcard reader 204, and/or to provide verification of the 
user's identity. In one embodiment, biometric sensor 1404 of 
the security system 1402 may capture an iris scan, when a 
user uses sensor 1404 to scan his iris while he may be up to 
five feet away from sensor 1404. Sensor 1404 may scan the 
user's iris through contacts, sunglasses, and/or any other 
type of eye glasses. Biometric sensor 1404 may be in 
communication with IC 110 such that sensor 1404 receives 
the iris scan and transmits a signal to the CPU to facilitate 
activating the operation of smartcard 202. A power source 
may be in communication with biometric sensor 1404 and 
IC 110 to provide the desired power for operation of the 
biometric security system components. 

[0180] Smartcard 202 may digitize the iris scan based on 
iris characteristics and compare the scan against a digitized 
iris scan stored in a database included on smartcard 202. The 
iris scan information may additionally be compared with 
information from one or more third-party databases com- 
municating with smartcard 202 through any communication 
software and/or hardware, including for example, smartcard 
reader 204, a USB connection, a wireless connection, a 
computer, a network and/or any other means for communi- 
cating. The CPU may facilitate the local comparison to 
authenticate the biometric and validate the information. Any 
of the embodiments may alternatively or additionally 
include remote comparisons performed or controlled by one 
or more third-party security vendors. 

[0181] For example, for iris scans, the CPU may utilize an 
existing database to compare the surface patterns of the iris 
by localizing the boundaries and the eyelid contours of the 
iris and creating a phase code for the texture sequence in the 
iris. This transfer of information may include use of encryp- 
tion, decryption, security keys, digital certificates and/or 
other security devices to confirm the security of the sample. 
Smartcard 202 may additionally communicate with third- 
party databases to facilitate a comparison between smartcard 
202 identifier and other smartcard identifiers stored with the 
biometric samples. Further, the present invention anticipates 
use of one or more third-party devices such as iris scan 
recognition software and/or hardware systems to facilitate 
iris scan comparisons, such as, for example those developed 
by Iridian, LG Electronics and BioCom. 

[0182] Smartcard 202 and/or any other third-party security 
vendor system used in connection with smartcard 202 may 
additionally be configured with secondary security proce- 
dures to confirm that fake biometric samples are not being 
used. For example, to detect the use of a false iris, system 



1402 may be further configured to vary the light shone into 
the eye to watch for pupil dilation, to detect body heat and/or 
any other secondary procedure to thwart biometric security 
fraud. After verifying the biometric information, smartcard 
202 and smartcard reader 204 may begin authentication by 
the methods described herein. 

[0183] In another exemplar'.' embodiment, biometric secu- 
rity system 1402 may be configured for facilitating biomet- 
ric security using retinal scanning biometries. As discussed 
herein, retinal scanning biometrics may include recognition 
of characteristics of the rellected retinal pattern of the eye, 
such as the location, structure, size, and shape of blood 
vessels and or any portion thereof. As discussed herein, 
these characteristics may be collectively referred to as a 
"retinal scan." Biometric security system 1402 may include 
a biometric sensor 1404 which may be configured with 
low-intensity light source, such as an infrared source, an 
optical coupler and/or other hardware and/or software that 
facilitates the capture of biometric data from the person such 
as, for example, scanning, detecting or otherwise sensing a 
retinal scan of cardmember. 

[0184] In one exemplary application of smartcard 202 
incorporating biometric security system 1402, system 1402 
may capture the iris scan of the cardmember to initiate the 
mutual authentication process between smartcard 202 and 
smartcard reader 204, and/or to provide verification of the 
user's identity. In one embodiment, biometric sensor 1404 of 
the security system 1402 may capture a retinal scan, when 
a sensor 1404 shines a light source into the user's retina and 
detects the reflected retina pattern. Sensor 1404 may detect 
a user's retinal pattern when the user may be up to five feet 
away from sensor 1404. Biometric sensor 1404 may be in 
communication with IC 110 such that sensor 1404 receives 
the retinal scan and transmits a signal to the CPU to facilitate 
activating the operation of smartcard 202. A power source 
may be in communication with biometric sensor 1404 and 
IC 110 to provide the desired power for operation of the 
biometric security system components. 

[0185] Smartcard 202 may digitize the retinal scan based 
on retinal characteristics and compare the scan against a 
digitized iris scan stored in a database included on smartcard 
202. The retinal scan information may additionally be com- 
pared with information from one or more third-party data- 
bases communicating w ith smartcard 202 through any com- 
munication software and/or hardware, including for 
example, smartcard reader 204, a USB connection, a wire- 
less connection, a computer, a network and/or any other 
means for communicating. The CPU may facilitate the local 
comparison to authenticate the biometric and validate the 
information. Any of the embodiments may alternatively or 
additionally include remote comparisons performed or con- 
trolled by one or more third-party security vendors. 

[0186] For example, for retinal scans, the CPU may utilize 
an existing database to compare the blood vessel patterns of 
the retina by comparing stored and detected retinal patterns. 
This transfer of information may include use of encryption, 
decryption, security keys, digital certificates and/or other 
security devices to confirm the security of the sample. 
Smartcard 202 may additionally communicate with third- 
party databases to facilitate a comparison between smartcard 
202 identifier and other smartcard identifiers stored with the 
biometric samples. Further, the present invention anticipates 
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use of one or more third-party devices such as retinal scan 
recognition software and/or hardware systems to facilitate 
keystroke scan comparisons, such as, for example those 
developed by EyeKey and Retinal Technologies. 

[0187] Smartcard 202 and/or any other third-party security 
vendor system used in connection with smartcard 202 may 
additionally be configured with secondary security proce- 
dures to confirm that fake biometric samples are not being 
used. For example, to detect the use of a false retina, system 
1402 may be further configured to vary the light shone into 
the eye to watch for pupil dilation, to detect body heat and or 
any other secondary procedure to thwart biometric security 
fraud. After verifying the biometric information, smartcard 
202 and smartcard reader 204 may begin authentication by 
the methods described herein. 

[0188] Additionally, smartcard 202 may be configured 
with a security verification mechanism to verify whether the 
sampled biometric and/or related information is staying on 
smartcard 202 and/or reader 204. The security verification 
mechanism may be used to safeguard biometric information 
from getting lost and/or compromised on the host system. 
[0189] In an additional or alternate embodiment, smart- 
card reader 204 may include one or more security system, 
wherein the security system incorporates one or more bio- 
metric system. As shown in FIG. 16, smartcard reader 204 
includes a biometric security system 1602 configured for 
facilitating biometric security using a biometric sample. 
Biometric security system 1602 may include a biometric 
sensor 1604 which may be configured with a sensor, video 
camera, digital camera, optical scanner, light source and/or 
other hardware and/or software for acquiring biometric data 
form the person such as, for example, optical scanning, 
chemical sensing, or otherwise detecting the portion of 
cardmember. Biometric sensor 1604 may be in communi- 
cation with a sensor interface/driver 1606 such lhal sensor 
interface 1606 receives biometric information and transmits 
a signal to the CPU to facilitate activating the operation of 
smartcard 202. 

[0190] In one exemplary application of smartcard reader 
204 including biometric security system 1602, the user may 
submit a biometric sample to the biometric sensor to initiate 
the mutual authentication process between smartcard 202 
and smartcard reader 204, and/or to provide verification of 
the user's identity. Smartcard reader 204 may digitize the 
sample and compare it against a digitized biometric sample 
stored in a database (e.g.. database 1610) included on 
smartcard reader 204. The biometric sample information 
may additionally be compared with information from one or 
more third-party databases communicating with smartcard 
202 through any communication software and/or hardware, 
including for example, smartcard 202, a USB connection, a 
wireless connection, a computer, a network and/or any other 
means for communicating. The transfer of information may 
include use of encryption decryption, security keys, digital 
certificates and/or other security devices to confirm the 
security of the sample. Smartcard reader 204 may addition- 
ally communicate with third-party databases to facilitate a 
comparison between smartcard 202 identifier and other 
smartcard identifiers stored with the biometric samples. 

[0191] A smartcard reader CPU 1614 may facilitate the 
local comparison to authenticate the biometric sample and 
may validate the information. Reader CPU 1614 may be 



configured in a manner similar to that of the CPU. Any of the 
embodiments may alternatively or additionally include 
remote comparisons performed or controlled by third-party 
security vendors in any way known in the art for comparing 
biometric data. 

[0192] Smartcard reader 204 may also be configured with 
secondary security procedures biometric to confirm that fake 
biometric samples are not being used. For example, smart- 
card reader 204 may be further configured to measure blood 
flow, body heat and/or any other secondary procedure to 
reduce biometric security fraud. Other security procedures 
for ensuring the authenticity of biometric samples may 
include monitoring pupil dilation for retinal and/or iris 
scans, pressure sensors, blinking sensors, human motion 
sensors, and/or any other procedures known in the art for 
authenticating the authenticity of biometric samples. After 
verifying the biometric information, smartcard 202 and 
smartcard reader 204 may begin authentication, and the 
transaction may proceed accordingly. 

[0193] Additionally, CPU 1614 may be configured with a 
security verification mechanism to verify whether the 
sampled biometric and/or related information is staying on 
smartcard 202 and/or reader 204. The security verification 
mechanism may be used to safeguard biometric information 
from getting lost and/or compromised on the host system. 

[0194] While the biometric safeguard mechanisms 
describe smartcard 202 and/or smartcard reader 204 config- 
ured with a biometric safeguard mechanism, any part of 
system 1400 may be equipped with a biometric safeguard 
system. For example, the invention contemplates receiving 
a biometric sample only at the reader, only at the smartcard, 
at both the smartcard and the reader, or at any other 
combination of location or device. As such, any scanner or 
database discussed herein may be located within or associ- 
ated with another device. For example, the smartcard may 
scan a user biometric, but the database used for comparison 
may be located within the reader or merchant server. In other 
embodiments, the biometric security device may be located 
away from the point of sale device and/or provide other 
functions. For example, the biometric security device may 
be located near the item to be purchased or located in any 
other location within or outside of the merchant. In one 
embodiment, the biometric security device may be located 
outside of a jewelry display to allow a user to not only start 
the authentication process before check-out, but also to 
allow access to the product within the display case. In this 
regard, the biometric security device may communicate the 
information to the point of sale device so access point 1450 
may verify that the person that entered the jewelry box is the 
same person that is now buying the jewelry. In another 
embodiment, any portion of system 1400 may be configured 
with a biometric security device. The biometric security 
device may be attached and/or free-standing. Biometric 
security devices may be configured for local and/or third- 
party operation. For example, the present invention contem- 
plates the use of third-party fingerprint scanning and security 
devices such as those made by Interlink hlectronics, 
Keytronic, Identix Biotouch, BIOmetricID, onClick, and/or 
other third-party vendors. 

[0195] In yet another embodiment, the database used for 
comparison may contain terrorist and/or criminal informa- 
tion. As used herein, terrorists and or criminals may include 
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terrorists, felons, criminals, convicts, indicted persons, 
insurgents, revolutionaries and/or other offenders. The infor- 
mation may include biometric information, personal infor- 
mation as described herein, arrest records, aliases used, 
country of residence, affiliations with gangs and terrorist 
groups, and/or any other terrorist and/or criminal informa- 
tion. 

[0196] As an example of a secondary security procedure in 
accordance with the present invention, the biometric sensor 
1404, 1604 may be configured to allow a finite number of 
scans. For example, biometric sensor 1404, 1604 may be 
configured to only accept data from a single scan. As a 
result, biometric sensor 1404, 1604 may turn off or deacti- 
vate smartcard 202 and/or smartcard reader 204 if more than 
one scan may be needed to obtain a biometric sample. 
Biometric sensor 1404, 1604 may also be configured to 
accept a preset limit of scans. For example, biometric sensor 
1404, 1604 may receive three invalid biometric samples 
before it turns off and/or deactivates smartcard 202 and/or 
smartcard reader 204. 

[0197] The sensor or any other part of system 1400 may 
also activate upon sensing a particular type or group of 
biometric samples. The activation may include sending a 
signal, blinking, audible sound, visual display, beeping, 
providing an olfactory signal, providing a physical touch 
signal, and providing a temperature signal to said user and or 
the like. For example, if the sensor detects information from 
a gold card member, the system may display a special offer 
on access point 1450. If the sensor detects a repeat customer, 
the sensor may signal or notify a manager to approach the 
customer and thank them for their repeat business. In 
another embodiment, the system may send a signal to a 
primary account holder or any other person or device to 
notify them that the smartcard is being used or that a 
condition or rule is being violated (e.g., charge above 
S1000). 

[0198] Any of the biometric security systems described 
herein may additionally be configured with a fraud protec- 
tion log. That is, a biometric security system, such as 
biometric security system 1402, 1602 may be configured to 
log all biometric samples submitted on smartcard 202 and/or 
smartcard reader 204 and store the log information on 
databases on and/or communicating with system 1402, 
1602. If a new and/or different biometric sample is submit- 
ted that differs from the log data, biometric security system 
1402, 1602 may employ a security procedure such as 
deactivation, warning authorities, requesting a secondary 
scan, and/or any other security procedure. 

[0199] Biometric security system 1402, 1602 and/or the 
biometric security system configured with system 1400 may 
also be configured to obtain a plurality of biometric samples 
for verification and/or other security purposes. For example, 
after biometric security system 1402, receives a first bio- 
metric sample (e.g., scans one finger), it may be configured 
to receive a second biometric sample (e.g., scans a second 
finger). The first and second biometric samples may be 
compared with stored biometric samples by any of the 
methods disclosed herein. The second biometric sample may 
be the only sample compared with stored biometric samples 
if the first sample may be unreadable or inadequate. 

[0200] In yet another exemplary embodiment of the 
present invention, smartcard 202 may be equipped with a 



biometric safeguard mechanism. For example, in one exem- 
plary application of smartcard 202, smartcard 202 may use 
biometric security system 1402 to authorize a transaction 
that violates an established rule, such as, for example, a 
purchase exceeding an established per purchase spending 
limit, a purchase exceeding a preset number of transactions, 
any portion of a purchase and/or transaction involving 
non-monetary funds (e.g., paying a portion of the transaction 
with loyalty points, coupons, airline miles, etc.) and/or any 
other purchase and/or transaction exceeding a preset or 
established limit. Cardmember, a third-party issuer system a 
third-party financial system, a company and/or any other 
entity or system may establish the preset limits. The limits 
may be used to prevent fraud, theft, overdrafts, and/or other 
non-desirable situations associated with financial and non- 
linancial accounts. For example, if smartcard 202 is stolen 
and the thief tries to make a large purchase with the card, the 
biometric safeguard mechanism may prevent the purchase 
until cardmember's identity is verified by biometric means. 
[0201] For example, smartcard 202 may activate biometric 
security system 1402 to notify a user a user who is attempt- 
ing to make a large purchase that the user must provide a 
biometric sample to verify the user's identity. By notifying, 
smartcard 202 may be configured to provide an audible 
signal, visual signal, optical signal, mechanical signal, vibra- 
tion, blinking, signaling, beeping, providing an olfactory 
signal, providing a physical touch signal, and providing a 
temperature signal to said user and/or provide any other 
notification to a cardmember. Accordingly, cardmember 
may provide such verification by submitting a biometric 
sample, for example placing his linger over biometric sensor 
1404 and/or any other biometric security devices used in 
association with smartcard 202. Biometric sensor 1404 may 
then digitize the biometric sample (e.g., fingerprint) and use 
the digitized sample for verification by any of the methods 
described herein. Once cardmember's identity and/or smart- 
card 202 smartcard chip identifier may be verified, smartcard 
202 may provide a transaction authorized signal to the CPU 
(and/or to IC 110) for forwarding to smartcard reader 204. 
Smartcard reader 204 may Ihen provide the transaction 
authorized signal to access point 1450 in a similar manner as 
is done with conventional PIN driven systems and access 
point 1450 may process the transaction under the merchant's 
business as usual standard. If smartcard 202 has been stolen, 
then cardmember's identity may not be verified and the 

further security procedures may be triggered, such as, for 
example, smartcard 202 may deactivate, smartcard 202 may 
send a notification to a security vendor, smartcard 202 may 
be confiscated by the merchant and/or any other security 
procedures may be used. 

[0202] In another exemplary embodiment, smartcard 
reader 204 may be equipped with a biometric safeguard 
mechanism. For example, in one exemplary application of 
smartcard reader 204, smartcard reader 204 may use bio- 
metric security system 1602 to authorize a transaction that 
violates an established rule, such as, for example, a purchase 
exceeding an established per purchase spending limit, a 
purchase exceeding a preset number of transactions and/or 
any other purchase exceeding a preset or established limit. 
Cardmember, a third-party issuer system a third-party finan- 
cial system, a company and/or any other entity or system 
may establish the preset limits. The limits may be used to 
prevent fraud, theft, overdrafts, and/or other non-desirable 
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situations associated with financial and non-financial 
accounts. For example, if smartcard 202 is stolen and the 
thief tries to make a large purchase with the card, the 
biometric safeguard mechanism may prevent the purchase 
until cardmember's identity is verified by biometric means. 
[0203] In one example, where cardmember is using a 
company-issued smartcard 202, smartcard 202 may the have 
a pre-set limit of transactions that may be completed before 
biometric verification is required. If the user exceeds the 
transaction limit, smartcard reader 204 may be configured to 
scan a biometric sample in order to verify the user's identity. 
Accordingly, the user may provide such verification by 
submitting a biometric sample, for example submitting a 
retinal scan to biometric sensor 1604. Smartcard reader 204 
may then digitize the biometric sample (e.g., retinal pattern) 
and use the digitized sample for verification by any of the 
methods described herein. Once cardmember's identity and/' 
or smartcard 202 smartcard chip identifier may be verified, 
smartcard reader 204 may receive a transaction authorized 
signal from a security vendor authorized to give such a 
signal. Smartcard reader 204 may then provide the transac- 
tion authorized signal to access point 1450 in similar manner 
as is done with conventional PIN driven systems and access 
point 1450 may process the transaction under the merchant's 
business as usual standard. 

[0204] While (lie biometric safeguard mechanisms 
described herein use fingerprint scanning and retinal scan- 
ning for biometric sample verification for exemplification, 
any biometric sample may be submitted for verification, 
authorization and or any other safeguard purpose, For 
example the present invention contemplates the use of voice 
recognition, facial and/or ear recognition, signature recog- 
nition, vascular patterns, DNA sampling, hand geometry, 
auditory emissions recognition, olfactory recognition, key- 
stroke/typing recognition, iris scans, and/or any other bio- 
metric known in the art. 

[0205] In another exemplary embodiment of the present 
invention, one or more biometric samples may be used to 
sign and/or encrypt information. For example, smartcard 
202 and/or reader 2500 may be configured to receive a 
biometric sample from a user. The sample may then be 
digitized and used, for example, as a variable in an encryp- 
tion calculation to secure data. If the user wants to retrieve 
the encrypted data, the user must submit the relevant bio- 
metric sample and have il aulhenlicaled by any of the 
methods described herein. Once the biometric sample is 
authenticated, the data will be decrypted for access. 

[0206] Similarly, a biometric may be used as both a private 
key and a public key for encryption purposes. In one 
exemplary embodiment, an entity may use stored biometric 
sample information to encrypt data in a manner similar to a 
public key. The data may then be configured such that it is 
only accessible by a real biometric sample, for example, by 
a user proffering a fingerprint sample at a reader. Upon 
verification of the real biometric sample, the data may be 
decrypted and/or retrieved. 

[0207] While the exemplary embodiments describe herein 
make reference to identification, authentication and autho- 
rization processes, it should be understood that the biometric 
security systems and methods described herein may be used 
for identification purposes only, authentication purposes 
only, and or authorization purposes only. Similarly, any 



combination of identification, authentication and/or autho- 
rization systems and methods may be used in conjunction 
with the present invention. 

[0208] The corresponding structures, materials, acts and 
equivalents of all elements in the claims below are intended 
to include any structure, material or acts for performing the 
functions in combination with other claimed elements as 
specifically claimed. The scope of the invention should be 
determined by the allowed claims and their legal equiva- 
lents, rather than by the examples given above. 

What is claimed is: 

1. A method for conducting a transaction in a transaction 
system, the method comprising: 

receiving a transaction request from a user, said user 
proffering a transaction instrument to facilitate said 
transaction request; 

issuing a challenge to said user; 

receiving a response from said user based upon said 
challenge; 

receiving a biometric al a biometric sensor to create a 
biometric sample, said biometric sensor communicat- 
ing with said transaction system to initiate verification 
of said biometric sample; and, 

processing said response to verify said transaction instru- 
ment and sard biometric sample to verily said riser and 
to provide access to a transaction service. 

2. The method of claim 1, further comprising the steps of: 

assembling credentials for said transaction at a server to 
create assembled credentials, said assembled creden- 
tials comprising at least one key; 

providing at least a portion of said assembled credentials 

receiving a second request from said user at said server, 
said second request comprising said portion of said 
assembled credentials provided to said user; and 

validating, at said server, said portion of said assembled 
credentials provided to said user with said key of said 
assembled credentials to provide access to said trans- 

3. The method of claim 1, wherein said transaction is an 
electronic purchase transaction. 

4. The method of claim 1, wherein said step of processing 
said response comprises processing said response to verify 
a smartcard. 

5. The method of claim 1, wherein said step of receiving 
said biometric further comprises receiving a registration of 
at least one biometric sample, wherein said registration 
comprises a proffered biometric sample. 

6. The method of claim 5, wherein said step of receiving 
said registration further comprises processing database 
information contained in at least one of a smartcard, smart- 
card reader, said biometric sensor, a remote server, a mer- 
chant server and a smartcard system. 

7. The method of claim 5, wherein said step of receiving 
said registration further comprises comparing said proffered 
biometric sample with a stored biometric sample. 

8. The method of claim 7, wherein said step of comparing 
further comprises comparing said proffered biometric 
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sample to said stored biometric sample by using at least one 
of a third-party security vendor device and a local CPU. 

9. The method of claim 1, wherein said step of receiving 
said biometric further comprises at least one of detecting, 
processing and storing a second biometric sample. 

10. The method of claim 1, wherein said step of receiving 
said biometric further comprises the use of at least one 
secondary security procedure. 

11. Amethod for conducting a transaction in a transaction 
system, the method comprising: 

detecting a proffered biometric at a sensor communicating 
with said transaction system to obtain a proffered 
biometric sample; 

detecting a proffered transaction instrument at a reader 
communicating with said transaction system; 

receiving transaction information from a user to facilitate 
issuing a challenge to said user to verify a user trans- 
action; 

initiating verification of said proffered biometric sample 
and said transaction instrument; and 

providing authorization of said transaction upon verifica- 
tion of said proffered biometric sample and transaction 
instrument. 

12. The method of claim 11, wherein said step of detecting 
said proffered biometric comprises detecting said biometric 
via at least one of a smartcard, a reader, and a network. 

13. The method of claim 11, wherein said step of detecting 
said proffered biometric further comprises at least one of 
storing and processing said proffered biometric sample. 

14. The method of claim 11, wherein said step of detecting 
said proffered biometric further comprises receiving a finite 
number of proffered biometric samples during said transac- 

15. The method of claim 11, wherein said step of detecting 
said proffered biometric further comprises at least one of 
detecting, processing and storing at least one second prof- 
fered biometric sample. 

16. The method of claim 1 1 , wherein said step of initiating 
verification comprises initiating a comparison of said prof- 
fered biometric sample with a stored biometric sample. 

17. An electronic transaction system comprising: 

a reader configured to communicate with a smartcard; 
a biometric sensor configured to detect a biometric 

a first device configured to receive a transaction request 
from a user, issue a challenge to said user, receive a 
response from said user based upon said challenge, 
process said response to verify said user, assemble 
credentials for a transaction at a server to create 
assembled credentials, and provide at least a portion of 
said assembled credentials to said user; and 

a second device configured to verify said biometric 
sample and said portion of said assembled credentials 
to facilitate said transaction. 

18. The electronic transaction system of claim 17, 
wherein said biometric sensor is configured to communicate 
with the other parts of said system via at least one of said 
smartcard, said reader, and a network. 



19. The electronic transaction system of claim 17, 
wherein said biometric sensor is configured to facilitate a 
finite number of scans. 

20. The electronic transaction system of claim 17, 
wherein said biometric sensor is configured to log at least 
one of said detected biometric sample, processed biometric 
sample and a stored biometric sample. 

21. The electronic transaction system of claim 17, 
wherein said first and second devices are configured to be 
the same device. 

22. The electronic transaction system of claim 17, 
wherein said reader is configured to be the same device as 
said biometric sensor. 

23. The electronic transaction system of claim 17, 
wherein said biometric sample comprises at least a portion 
of one of said user's: voice, fingerprint, facial features, ear 
features, sound signature, handwriting signature, vascular 
patterns, DNA, hand geometry, smell, keystroke/typing fea- 
tures, iris, retina, and brainwaves. 

24. The electronic transaction system of claim 17, 
wherein said second device is configured to compare said 
proffered biometric sample with a stored biometric sample. 

25. The electronic transaction system of claim 24, 
wherein said second device is configured to compare at least 
one characteristic of said biometric samples, and wherein 
said characteristics of said biometric samples include at least 
one of minutia, vascular patterns, prints, waveforms, odor- 
ants, nodal points, reference points, size, shape, thermal 
patterns, blood flow, and body heat. 

26. The electronic transaction system of claim 24, 
wherein said stored biometric sample comprises a registered 
biometric sample. 

27. The electronic transaction system of claim 17, 
wherein said biometric sample is primarily associated with 
at least one of first user information, wherein said first 
information comprises personal information, charge card 
information, debit card information, savings account infor- 
mation, membership information, PayPal account informa- 
tion, Western Union Account information, electronic bill 
payment information, automatic bill payment information 
and loyalty point information, and wherein said biometric 
sample is secondarily associated with at least one of second 
user information, wherein said second information com- 
prises personal information, credit card information, debit 
card information, savings account information, membership 
information, PayPal account information, Western Union 
Account information, electronic bill payment information, 
automatic bill payment information and loyalty point infor- 
mation, and wherein said second user information is differ- 
ent than said first user information. 

28. The electronic transaction system of claim 17, 
wherein said system is configured to begin authentication 
upon verification of said proffered biometric sample and 
portion of said assembled credentials. 

29. The electronic transaction system of claim 17, 
wherein said sensor is configured to provide a notification 
upon detection of said biometric sample. 

30. The electronic transaction system of claim 17, 
wherein said second device is configured to facilitate the use 
of at least one secondary security procedure. 
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31. A computer-readable storage medium containing a set 
of instructions for a general purpose computer configured 
for: 

receiving a transaction request from a user, said user 

proffering a transaction instrument; 
issuing a challenge to said user; 

receiving a response from said user based upon said 
challenge; 



receiving a biometric at a biometric sensor to create a 
biometric sample, said biometric sensor communicat- 
ing with said system to initiate verification of said 
biometric sample; and, 

processing said response to verify said transaction instru- 
ment and processing said biometric sample to verify 
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